contact. The party or parties might constitute a list of alternative 
clearinghouse providers for the traveling object from which the 
user selects his desired contact). 

As mentioned above, traveling objects enable objects 300 to 
be distributed "Out-Of-Channel; a that is, the object may be 
distributed by an unauthorized or not explicitly authorized 
individual to another individual. "Out of channel" includes paths 
of distribution that allow, for example, a user to directly 
redistribute an object to another individual. For example, an 
object provider might allow users to redistribute copies of an 
object to their friends and associates (for example by physical 
delivery of storage media or by delivery over a computer network) 
such that if a friend or associate satisfies any certain criteria 
required for use of said object, he may do so. 

For example, if a software program was distributed as a 
traveling object, a user of the program who wished to supply it or 
a usable copy of it to a friend would normally be free to do so. 
Traveling Objects have great potential commercial significance, 
since useful content could be primarily distributed by users and 
through bulletin boards, which would require little or no 
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distribution overhead apart from registration with the "original" 
content provider and/or clearinghouse. 

The "out of channel" distribution may also allow the 
5 provider to receive payment for usage and/or elsewise maintain 

at least a degree of control over the redistributed object. Such 
certain criteria might involve, for example, the registered 
presence at a user's VDE node of an authorized third party 
financial relationship, such as a credit card, along with sufficient 
10 available credit for said usage. 

Thus, if the user had a VDE node, the user might be able to 
use the traveling object if he had an appropriate, available 
budget available on his VDE node (and if necessary, allocated to 
15 him), and/or if he or his VDE node belonged to a specially 

authorized group of users or installations and/or if the traveling 
object carried its own budgets). 

Since the content of the traveling object is encrypted, it can 
20 be used only under authorized circumstances unless the traveling 

object private header key used with the object is broken — a 
potentially easier task with a traveling object as compared to, for 
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example, permissions and/or budget information since many 
objects may share the same key, giving a cryptoanalyst both more 
information in cyphertext to analyze and a greater incentive to 
perform cryptoanalysis. 

In the case of a "traveling object," content owners may 
distribute information with some or all of the key blocks 810 
included in the object 300 in which the content is encapsulated. . 
Putting keys in distributed objects 300 increases the exposure to 
attempts to defeat security mechanisms by breaking or 
cryptoanalyzing the encryption algorithm with which the private 
header is protected (e.g., by determining the key for the header's 
encryption). This breaking of security would normally require 
considerable skill and time, but if broken, the algorithm and key 
could be published so as to allow large numbers of individuals 
who possess objects that are protected with the same key(s) and 
algorithm(s) to illegally use protected information. As a result, 
placing keys in distributed objects 300 may be limited to content 
that is either "time sensitive" (has reduced value after the 
passage of a certain period of time), or which is somewhat limited 
in value, or where the commercial value of placing keys in objects 
(for example convenience to end-users, lower cost of eliminating 
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the telecommunication or other means for delivering keys and/or 
permissions information and/or the ability to supporting objects 
going "out-of-channeD exceeds the cost of vulnerability to 
sophisticated hackers. As mentioned elsewhere, the security of 
5 keys may be improved by employing convolution techniques to 

avoid storing "true* keys in & traveling object, although in most 
cases using a shared secret provided to most or all VDE nodes by 
a VDE administrator as an input rather than site ID and/or time 
in order to allow objects to remain independent of these values. 

As shown in Figure 19 and discussed above, a traveling 
object contains a permissions record 808 that preferably provides 
at least some budget (one, the other, or both, in a general case). 
Permission records 808 can, as discussed above, contain a key 

15 block(s) 810 storing important key information. PERC 808 may 

also contain or refer to budgets containing potentially valuable 
quantities/values. Such budgets may be stored within a traveling 
object itself, or they may be delivered separately and protected by 
highly secure co mmunic ations keys and administrative object 

20 keys and management database techniques. 
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The methods 1000 contained by a traveling object will 
typically include an installation procedure for "self registering" 
the object using the permission records 808 in the object (e.g., a 
REGISTER method). This may be especially useful for objects 
that have time limited value, objects (or properties) for which the 
end user is either not charged or is charged only a nominal fee 
(e.g., objects for which advertisers and/or information publishers 
are charged based on the number of end users who actually 
access published information), and objects that require widely 
available budgets and may particularly benefit from 
out-of-channel distribution (e.g., credit card derived budgets for 
objects containing properties such as movies, software programs, 
games, etc.). Such traveling objects may be supplied with or 
without contained budget UDEs. 

One use of traveling objects is the publishing of software, 
where the contained permission record(s) may allow potential 
customers to use the software in a demonstration mode, and 
possibly to use the full program features for a limited time before 
having to pay a license fee, or before having to pay more than an 
initial trial fee. For example, using a time based billing method 
and budget records with a small pre-inst ailed time budget to 
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allow full use of the program for a short period of time. Various 
control methods may be used to avoid misuse of object contents. 
For example, by setting the minimum registration interval for 
the traveling object to an appropriately large period of time (e.g., 
5 a month, or six months or a year), users are prevented from 

re-using the budget records in the same traveling object. 

Another method for controlling the use of traveling objects 
is to include time-aged keys in the permission records that are 

10 incorporated in the traveling object. This is useful generally for 

traveling objects to ensure that they will not be used beyond a 
certain date without re-registration, and is particularly useful for 
traveling objects that are electronically distributed by broadcast, 
network, or teleco mmuni cations (including both one and two way 

15 cable), since the date and time of delivery of such traveling 

objects aging keys can be set to accurately correspond to the time 
the user came into possession of the object. 

Traveling objects can also be used to facilitate "moving" an 
20 object from one electronic appliance 600 to another. A user could 

move a traveling object, with its incorporated one or more 
permission records 808 from a desktop computer, for example, to 
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his notebook computer. A traveling object might register its user 
within itself and thereafter only be useable by that one user. A 
traveling object might maintain separate budget information, one 
for the basic distribution budget record, and another for the 
5 "active" distribution budget record of the registered user. In this 

way, the object could be copied and passed to another potential 
user, and then could be a portable object for that user. 

Traveling objects can come in a container which contains 
10 other objects. For example, a traveling object container can 

include one or more content objects and one or more 
administrative objects for registering the content object(s) in an 
end user's object registry and/or for providing mechanisms for 
enforcing permissions and/or other security functions. Contained 
15 administrative object(s) may be used to install necessary 

permission records and/or budget information in the end user's 
electronic appliance. 



Content Objects 

20 Figure 20 shows an example of a VDE content object 

structure 880. Generally, content objects 880 include or provide 
information content. This "content" may be any sort of electronic 
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information. For example, content may include: computer 
software, movies, books, music, information databases, 
multimedia information, virtual reality information, machine 
instructions, computer data files, communications messages 
and/or signals, and other information, at least a portion of which 
is used and/or manipulated by one or more electronic appliances. 
VDE 100 can also be configured for authenticating, controlling, 
and/or auditing electronic commercial transactions and 
communications such as inter-bank transactions, electronic 
purchasing co mmunic ations, and the transmission of, auditing of, 
and secure commercial archiving of, electronically signed 
contracts and other legal documents; the information used for 
these transactions may also be termed "content." As mentioned 
above, the content need not be physically stored within the object 
container but may instead be provided separately at a different 
time (e.g., a real time feed over a cable). 

Content object structure 880 in the particular example 
shown in Figure 20 is a type of stationary object because it does 
not include a PERC 808. In this example, content object 
structure 880 includes, as at least part of its content 812, at least 
one embedded content object 882 as shown in Figure 5A. 
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Content object structure 880 may also include an administrative 
object 870. Thus, objects provided by the preferred embodiment 
may include one or more "embedded" objects. 

Administrative Objects 

Figure 21 shows an example of an administrative object 
structure 870 provided by the preferred embodiment. An 
"administrative object" generally contains permissions, 
administrative control information, computer software and/or 
methods associated with the operation of VDE 100. 
Administrative objects may also or alternatively contain records 
of use, and/or other information used in, or related to, the 
operation of VDE 100. An administrative object may be 
distinguished from a content object by the absence of VDE 
protected "content" for release to an end user for example. Since 
objects may contain other objects, it is possible for a single object 
to contain one or more content containing objects and one or more 
administrative objects. Administrative objects may be used to 
transmit information between electronic appliances for update, 
usage reporting, billing and/or control purposes. They contain 
information that helps to administer VDE 100 and keep it 
operating properly. Administrative objects generally are sent 
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between two VDE nodes, for example, a VDE clearinghouse 
service, distributor, or client administrator and an end user's 
electronic appliance 600. 

Administrative object structure 870 in this example 
includes a public header 802, private header 804 (including a 
"PERC" 808) and a "private body" 806 containing methods 1000. 
Administrative object structure 870 in this particular example 
shown in Figure 20 is a type of traveling object because it 
contains a PERC 808, but the administrative object could exclude 
the PERC 808 and be a stationary object. Rather than storing 
information content, administrative object structure 870 stores 
"administrative information content" 872. Administrative 
information content 872 may, for example, comprise a number of 
records 872a, 872b, . . . 872n each corresponding to a different 
"event." Each record 872a, 872b, . . . 872n may include an "event" 
field 874, and may optionally include a parameter field 876 
and/or a data field 878. These administrative content records 
872 may be used by VDE 100 to define events that may be 
processed during the course of transactions, e.g., an event 
designed to add a record to a secure database might include 
parameters 896 indicating how and where the record should be 
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stored and data field 878 containing the record to be added. In 
another example, a collection of events may describe a financial 
transaction between the creator(s) of an administrative object 
and the recipient(s), such as a purchase, a purchase order, or an 
invoice. Each event record 872 may be a set of instructions to be 
executed by the end user's electronic appliance 600 to make an 
addition or modification to the end user's secure database 610, for 
example. Events can perform many basic management 
functions, for example: add an object to the object registry, 
including providing the associated user/group record(s), rights 
records, permission record and/or method records; delete audit 

♦ 

records (by "rolling up" the audit trail information into, for 
example, a more condensed, e.g. summary form, or by actual 
deletion); add or update permissions records 808 for previously 
registered objects; add or update budget records; add or update 
user rights records; and add or update load modules. 

In the preferred embodiment, an administrative object may 
be sent, for example, by a distributor, client administrator, or, 
perhaps, a clearinghouse or other financial service provider, to an 
end user, or, alternatively, for example, by an object creator to a 
distributor or service clearinghouse. Administrative objects, for 
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example, may increase or otherwise adjust budgets and/or 
permissions of the receiving VDE node to which the 
administrative object is being sent. Similarly, administrative 
objects cont ainin g audit information in the data area 878 of an 
5 event record 872 can be sent from end users to distributors, 

and/or clearinghouses and/or client administrators, who might 
themselves further transmit to object creators or to other 
participants in the objects chain of handling. 

10 Methods 

Methods 1000 in the preferred embodiment support many 
of the operations that a user encounters in using objects and 
communicating with a distributor. They may also specify what 
method fields are displayable to a user (e.g., use events, user 

15 request events, user response events, and user display events). 

Additionally, if distribution capabilities are supported in the 
method, then the method may support distribution activities, 
distributor comm unic ations with a user about a method, method 
modification, what method fields are displayable to a distributor, 

20 and any distribution database checks and record keeping (e.g., 

distribution events, distributor request events, and distributor 
response events). 
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Given the generality of the existing method structure, and 
the diverse array of possibilities for assembling methods, a 
generalized structure may be used for establishing relationships 
between methods. Since methods 1000 may be independent of an 
5 object that requires them during any given session, it is not 

possible to define the relationships within the methods 
themselves. "Control methods" are used in the preferred 
embodiment to define relationships between methods. Control 
methods may be object specific, and may accommodate an 
10 individual object's requirements during each session. 

A control method of an object establishes relationships 
between other methods. These relationships are parameterized 
with explicit method identifiers when a record set reflecting 
15 desired method options for each required method is constructed 

during a registration process. 

An "aggregate method" in the preferred embodiment 
represents a collection of methods that may be treated as a single 
20 unit . A collection of methods that are related to a specific 

property, for example, may be stored in an aggregate method. 
This type of aggregation is useful from an implementation point 
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of view because it may reduce bookkeeping overhead and may 
improve overall database efficiency. In other cases, methods may 
be aggregated because they are logically coupled. For example, 
two budgets may be linked together because one of the budgets 
represents an overall limitation, and a second budget represents 
the current limitation available for use. This would arise if, for 
example, a large budget is released in small amounts over time. 

For example, an aggregate method that includes meter, 
billing and budget processes can be used instead of three 
separate methods. Such an aggregate method may reference a 
s ing le "load module" 1100 that performs all of the functions of the 
three separate load modules and use only one user data element 
that contains meter, billing and budget data. Using an aggregate 
method instead of three separate methods may minimiz e overall 
memory requirements, database searches, decryptions, and the 
number of user data element writes back to a secure database 
610. The disadvantage of using an aggregate method instead of 
three separate methods can be a loss of some flexibility on the 
part of a provider and user in that various functions may no 
longer be independently replaceable. 
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Figure 16 shows methods 1000 as being part of secure 
database 610. 

A "method" 1000 provided by the preferred embodiment is 
5 a collection of basic instructions and information related to the 

basic instructions, that provides context, data, requirements 
and/or relationships for use in performing, and/or preparing to 
perform, the basic instructions in relation to the operation of one 
or more electronic appliances 600. As shown in Figure 16, 
10 methods 1000 in the preferred embodiment are represented in 

secure database 610 by: 

C method "cores* 1000N; 
C Method Data Elements (MDEs) 1202; 
C User Data Elements (UDEs) 1200; and 
15 C Data Description Elements (DTDs). 

Method "core" 1000N in the preferred embodiment may 
contain or reference one or more data elements such as MDEs 
1202 and UDEs 1200. In the preferred embodiment, MDEs 1202 
20 and UDEs 1200 may have the same general characteristics, the 

main difference between these two types of data elements being 
that a UDE is preferably tied to a particular method as well as a 
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particular user or group of users, whereas an MDE may be tied to 
a particular method but may be user independent. These MDE 
and UDE data structures 1200, 1202 are used in the preferred 
embodiment to provide input data to methods 1000, to receive 
data outputted by methods, or both. MDEs 1202 and UDEs 1200 
may be delivered independently of method cores 1000N that 
reference them, or the data structures may be delivered as part of 
the method cores. For example, the method core 1000N in the 
preferred embodiment may contain one or more MDEs 1202 
and/or UDEs 1200 (or portions thereof). Method core 1000N may, 
alternately or in addition, reference one or more MDE and/or 
UDE data structures that are delivered independently of method 
core(s) that reference them. 

Method cores 1000N in the preferred embodiment also 
reference one or more load modules" 1100, Load modules 1100 
in the preferred embodiment comprise executable code, and may 
also include or reference one or more data structures called "data 
descriptor" ("DTD") information. This "data descriptor" 
information may, for example, provide data input information to 
the DTD interpreter 590. DTDs may enable load modules 1100 
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to access (e.g., read from and/or write to) the MDE and/or UDE 
data elements 1202, 1200. 

Method cores 1000' may also reference one or more DTD 
5 and/or MDE data structures that contain a textual description of 

their operations suitable for inclusion as part of an electronic 
contract. The references to the DTD and MDE data structures 
may occur in the private header of the method core 1000', or may 
be specified as part of the event table described below. 

10 

Figure 22 shows an example of a format for a method core 
1000N provided by the preferred embodiment. A method core 
1000N in the preferred embodiment contains a method event table 
1006 and a method local data area 1008. Method event table 

15 1006 lists "events." These "events" each reference "load modules" 

1100 and/or PERCs 808 that control processing of an event. 
Associated with each event in the list is any static data necessary 
to parameterize the load module 1000 or permissions record 808, 
and reference(s) into method user data area 1008 that are needed 

20 to support that event. The data that parameterizes the load 

module 1100 can be thought of, in part, as a specific function call 
to the load module, and the data elements corresponding to it 
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may be thought of as the input and/or output data for that 
specific function call. 

Method cores 1000N can be specific to a single user, or they 
may be shared across a number of users (e.g., depending upon the 
uniqueness of the method core and/or the specific user data 
element). Specifically, each user/group may have its own UDE 
1200 and use a shared method core 1000N. This structure allows 
for lower database overhead than when associating an entire 
method core 1000N with a user/group. To enable a user to use a 
method, the user may be sent a method core 1000N specifying a 
UDE 1200. If that method core 1000N already exists in the site's 
secure database 610, only the UDE 1200 may need to be added. 
Alternately, the method may create any required UDE 1200 at 
registration time. 

The Figure 22 example of a format for a method core 1000N 
provided by the preferred embodiment includes a public 
(unencrypted) header 802, a private (encrypted) header 804, 
method event table 1006, and a method local data area 1008. 
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An example of a possible field layout for method core 1000N 
public header 802 is shown in the following table: 



Field Type 


Description 


Method ID 


Creator ID 


Site ID of creator of this method. 


Distributor ED 


Distributor of this method (e.g., last 
change). 


Type ID 


Constant, indicates method "tvpe." 


Method ID 


Unique sequence number for this 
method. 


Version ID 


Version number of this method. 


Other 

classification 
information 


Class ID 


ID to support different method 
"classes." 


Type ID 


ID to support method type 
compatible searching. 


Descriptive 
Information 


Description^) 


Textual descriptions ) of the 
method. 


Event Summary 


Summary of event classes (e.g., 
USE) that this method supports. 



An example of a possible field layout for private header 804 
is shown below: 
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Field Type 


Description 


Copy of Public Header 802 Method ID 
and "Other Classification 
Information" 


Method ID from Public Header 


Descriptive 
Information 


# of Events 


# of events supported in this 
method. 


Access and 
Reference Tags 


Access tag 


Tags used to determine if this 
method is the correct method 
under management by the SPU; 
ensure that the method core 1000N 
is used only under appropriate 
circumstances. 


Validation tag 


Correlation tag 


Data Structure Reference 


Optional Reference to DTD(s) 
and/or MDE(s) 


Check Value 


Check value for Private Header 
and method event table. 


Check Value for Public Header 


Check Value for Public Header 



Referring once again to Figure 22, method event table 1006 
15 may in the preferred embodiment include from 1 to N method 

event records 1012. Each of these method event records 1012 
corresponds to a different event the method 1000 represented by 
method core 1000N may respond to. Methods 1000 in the 
preferred embodiment may have completely different behavior 
20 depending upon the event they respond to. For example, an 
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AUDIT method may store information in an audit trail UDE 
1200 in response to an event corresponding to a user's use of an 
object or other resource. This same AUDIT method may report 
the stored audit trail to a VDE administrator or other participant 
in response to an administrative event such as, for example, a 
timer expiring within a VDE node or a request from another VDE 
participant to report the audit trail. In the preferred 
embodiment, each of these different events may be represented 
by an "event code." This "event code" may be passed as a 
parameter to a method when the method is called, and used to 
"look up" the appropriate method event record 1012 within 
method event table 1006. The selected method event record 
1012, in turn, specifies the appropriate information (e.g., load 
module(s) 1100, data element UDE(s) and MDE(s) 1200, 1202, 
and/or PERC(s) 808) used to construct a component assembly 690 
for execution in response to the event that has occurred. 

Thus, in the preferred embodiment, each method event 
record 1012 may include an event field 1014, a LM/PERC 
reference field 1016, and any number of data reference fields 
1018. Event fields 1014 in the preferred embodiment may 
contain a "event code" or other information identifying the 
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corresponding event. The LM/PERC reference field 1016 may 
provide a reference into the secure database 610 (or other 
"pointer" information) identifying a load module 1100 and/or a 
PERC 808 providing (or referencing) executable code to be loaded 
and executed to perform the method in response to the event. 
Data reference fields 1018 may include information referencing a 
UDE 1200 or a MDE 1202. These data structures may be 
contained in the method local data area 1008 of the method core 
1000N, or they may be stored within the secure database 610 as 
independent deliverables. 



The following table is an example of a possible more 
detailed field layout for a method event record 1012: 



Field Type 


Description 


Event Field 1014 


Identifies corresponding event. 


Access tag 


Secret tag to grant access to this row 
of the method event record. 


LM/PERC 
Reference 
Field 1016 


DB ID or offset/size 


Database reference (or local pointer). 


Correlation tag 


Correlation tag to assert when 
referencing this element. 
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Field Type 


Description 


# of Data Element Reference Fields 


Count of data reference fields in the 
method event record. 


Data 
Reference 
Field 1 


UDE ID or 
offset/size 


Database 610 reference (or local 
pointer). 


Correlation tag 


Correlation tag to assert when 
referencing this element. 


! 


Data 
Reference 
Field n 


UDE ID or 

offset/size 


Database 610 reference (or local 
pointer). 


Correlation tag 


Correlation tag to assert when 
referencing this element. 



Load Modules 

Figure 23 is an example of a load module 1100 provided by 
the preferred embodiment. In general, load modules 1100 
represent a collection of basic functions that are used for control 
operations. 

Load module 1100 contains code and static data (that is 
functionally the equivalent of code), and is used to perform the 
basic operations of VDE 100. Load modules 1100 will generally 
be shared by all the control structures for all objects in the 
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system, though proprietary load modules are also permitted. 
Load modules 1100 may be passed between VDE participants in 
administrative object structures 870, and are usually stored in 
secure database 610. They are always encrypted and 
5 authenticated in both of these cases. When a method core 1000N 

references a load module 1100, a load module is loaded into the 
SPE 503, decrypted, and then either passed to the electronic 
appliance microprocessor for executing in an HPE 655 (if that is 
where it executes), or kept in the SPE (if that is where it 
10 executes). If no SPE 503 is present, the load module may be 

decrypted by the HPE 655 prior to its execution. 



Load module creation by parties is preferably controlled by 
a certification process or a ring based SPU architecture. Thus, 
15 the process of creating new load modules 1100 is itself a 

controlled process, as is the process of replacing, updating or 
deleting load modules already stored in a secured database 610. 



A load module 1100 is able to perform its function only 
20 when executed in the protected environment of an SPE 503 or an 

HPE 655 because only then can it gain access to the protected 
elements (e.g., UDEs 1200, other load modules 1100) on which it 
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operates. Initiation of load module execution in this environment 
is strictly controlled by a combination of access tags, validation 
tags, encryption keys, digital signatures and/or correlation tags. 
Thus, a load module 1100 may only be referenced if the caller 
knows its ID and asserts the shared secret correlation tag specific 
to that load module. The decrypting SPU may match the 
identification token and local access tag of a load module after 
decryption. These techniques make the physical replacement of 
any load module 1100 detectable at the next physical access of 
the load module. Furthermore, load modules 1100 may be made 
"read only" in the preferred embodiment. The read-only nature 
of load modules 1100 prevents the write-back of load modules 
that have been tampered with in non-secure space. 

Load modules are not necessarily directly governed by 
PERCs 808 that control them, nor must they contain any 
time/date information or expiration dates. The only control 
consideration in the preferred embodiment is that one or more 
methods 1000 reference them using a correlation tag (the value of 
a protected object created by the load module's owner, distributed 
to authorized parties for inclusion in their methods, and to which 
access and use is controlled by one or more PERCs 808). If a 
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method core 1000N references a load module 1100 and asserts the 
proper correlation tag (and the load module satisfies the internal 
tamper checks for the SPE 503), then that load module can be 
loaded and executed, or it can be acquired from, shipped to, 
updated, or deleted by, other systems. 

As shown in Figure 23, load modules 1100 in the preferred 
embodiment may be constructed of a public (unencrypted) header 
802, a private (encrypted) header 804, a private body 1106 
containing the encrypted executable code, and one or more data 
description elements ("DTDs") 1108. The DTDs 1108 may be 
stored within a load module 1100, or they may be references to 
static data elements stored in secure database 610. 

The following is an example of a possible field layout for 
load module public header 802: 



Field Type 


Description 


LM ED 




VDE ED of Load Module. 




Creator ED 


Site ED of creator of this load module. 




Type ED 


Constant indicates load module tvne. 
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Field Type 


Description 




LM ED 


Unique sequence number for this load 
module, which uniquely identifies the 
load module in a sequence of load 
modules created by an authorized VDE 
participant. 


Version ID 


Version number of this load module. 


Other 

classification 
information 


Class ID 


ID to support different load module 
classes. 


Type ID 


ID to support method type compatible 
searching. 


Descriptive 
Information 


Description 


Textual description of the load module. 


Execution space 
code 


Value that describes what execution 
space (e.g., SPE or HPE) this load 
module. 



Many load modules 1100 contain code that executes in an 
SPE 503. Some load modules 1100 contain code that executes in 
an HPE 655. This allows methods 1000 to execute in whichever 
environment is appropriate. For example, an INFORMATION 
method 1000 can be built to execute only in SPE 503 secure space 
for government classes of security, or in an HPE 655 for 
commercial applications. As described above, the load module 
public header 802 may contain an "execution space code" field 
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that indicates where the load module 1100 needs to execute. This 
functionality also allows for different SPE instruction sets as well 
as different user platforms, and allows methods to be constructed 
without dependencies on the underlying load module instruction 
set. 

Load modules 1100 operate on three major data areas: the 
stack, load module parameters, and data structures. The stack 
and execution memory size required to execute the load module 
1100 are preferably described in private header 804, as are the 
data descriptions from the stack image on load module call, 
return, and any return data areas. The stack and dynamic areas 
are described using the same DTD mechanism. The following is 
an example of a possible layout for a load module private header 
1104: 
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Field Type 


Description 


Copy of some or 

puuiic UcUUCl o 


all of information ft 


ooObject ID from Public Header. 


Other 

classification 
information 


f*YiA#»1r ValnA 

i_/necK vaiue 


Check Value for Public Header. 


Descriptive 
Information 


LM Size 


Size of executable code block. 


LM Exec Size 


Executable code size for the load modul 


LM Exec Stack 


Stack size required for the load module 


Execution space c< 


»d£ode that describes the execution spac 
load module. 


Access and 
reference tagB 


Access tag 


Tags used to determine if the load mod 
correct LM requested by the SPE. 


Validation tag 


Correlation tag 


Tag used to determine if the caller of th 
the right to execute this LM. 


Digital Signature 


Used to determine if the LM executable 

in into 1*4: onH Tract rronioH Kv a tvnatori 0 

with a correct certificate for creating L 


Data record 

descriptor 

information 


DTD count 


Number of DTDs that follow the code bl 


DTD 1 reference 


If locally defined, the physical size and 
bytes of the first DTD defined for this L 

If publicly referenced DTD, this is the 
and the correlation tag to permit access 
record. 


*»* 
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DTD N reference 


If locally defined, the physical size and 
bytes of the Nth DTD defined for this L 

If publicly referenced DTD, this is the 
and the correlation tag to permit access 
record. 


Check Value 


Check Value for entire LM. 



Each load module 1100 also may use DTD 1108 
5 information to provide the information necessary to support 

building methods from a load module. This DTD information 
contains the definition expressed in a language such as SGML for 
the names and data types of all of the method data fields that the 
load module supports, and the acceptable ranges of values that 
10 can be placed in the fields. Other DTDs may describe the 

function of the load module 1100 in English for inclusion in an 
electronic contract, for example. 

The next section of load module 1100 is an encrypted 
15 executable body 1106 that contains one or more blocks of 

encrypted code. Load modules 1100 are preferably coded in the 
"native" instruction set of their execution environment for 
efficiency and compactness. SPU 500 and platform providers 
may provide versions of the standard load modules 1100 in order 
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to make their products cooperate with the content in distribution 
mechanisms contemplated by VDE 100. The preferred 
embodiment creates and uses native mode load modules 1100 in 
lieu of an interpreted or "p-code" solution to optimize the 
5 performance of a limited resource SPU. However, when sufficient 

SPE (or HPE) resources exist and/or platforms have sufficient 
resources, these other implementation approaches may improve 
the cross platform utility of load module code. 
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The following is an example of a field layout for a load 
module DTD 1108: 



Field Type 


Description 


DTD ID 




Uses Object ID from Private Header. 


Creator ID 


Site ID of creator of this DTD. 


Type ID 


Constant. 


DTD ID 


Unique sequence number for this DTD. 


Version ID 


Version number of this DTD. 


jjeBcnpuve 
Information 


DTD Size 


Size of DTD block. 


Access and 
reference tags 


Access tag 


Tags used to determine if the DTD is the 
DTD requested by the SPE. 


Validation tag 


Correlation tag 


Tag used to determine if the caller of this 
the right to use the DTD. 


DTD Body 


DTD Data Definition 1 


DTD Data Definition 2 


! 


DTD Data Definition N 


Check Value 


Check Value for entire DTD record. 



Some examples of how load modules 1100 may use DTDs 
1108 include: 
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C Increment data element (defined by name in DTD3) 
value in data area DTD4 by value in DTD1 

C Set data element (defined by name in DTD3) value 
in data area DTD4 to value in DTD3 

C Compute atomic element from event in DTDl from 
table in DTD3 and return in DTD2 

C Compute atomic element from event in DTDl from 
equation in DTD3 and return in DTD2 

C Create load module from load module creation 
template referenced in DTD3 

C Modify load module in DTD3 using content in DTD4 

C Destroy load module named in DTD3 

Commonly used load modules 1100 may be built into a 
SPU 500 as space permits. VDE processes that use built-in load 
modules 1100 will have significantly better performance than 
processes that have to find, load and decrypt external load 
modules. The most useful load modules 1100 to build into a SPU 
might include scaler meters, fixed price b illing , budgets and load 
modules for aggregate methods that perform these three 
processes. 
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User Data Elements (UDEs) 1200 and Method Data Elements 
(MDEs) 1202 

User Data Elements (UDEs) 1200 and Method Data 
Elements (MDEs) 1202 in the preferred embodiment store data. 
There are many types of UDEs 1200 and MDEs 1202 provided by 
the preferred embodiment. In the preferred embodiment, each of 
these different types of data structures shares a common overall 
format including a common header definition and naming 
scheme. Other UDEs 1200 that share this common structure 
include "local name services records" (to be explained shortly) 
and account information for connecting to other VDE 
participants. These elements are not necessarily associated with 
an individual user, and may therefore be considered MDEs 1202. 
All UDEs 1200 and all MDEs 1202 provided by the preferred 
embodiment may, if desired, (as shown in Figure 16) be stored in 
a common physical table within secure database 610, and 
database access processes may commonly be used to access all of 
these different types of data structures. 

In the preferred embodiment, PERCs 808 and user rights 
table records are types of UDE 1200. There are many other types 
of UDEs 1200/MDEs 1202, including for example, meters, meter 
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trails, budgets, budget trails, and audit trails. Different formats 
for these different types of UDEs/MDEs are defined, as described 
above, by SGML definitions contained within DTDs 1108. 
Methods 1000 use these DTDs to appropriately access 
5 UDEs/MDEs 1200, 1202. 

Secure database 610 stores two types of items: static and 
dynamic. Static data structures and other items are used for 
information that is essentially static information. This includes 

10 load modules 1100, PERCs 808, and many components of 

methods. These items are not updated frequently and contain 
expiration dates that can be used to prevent "old" copies of the 
information from being substituted for newly received items. 
These items may be encrypted with a site specific secure 

15 database file key when they are stored in the secure database 

610, and then decrypted using that key when they are loaded into 
the SPE. 

Dynamic items are used to support secure items that must 
20 be updated frequently. The UDEs 1200 of many methods must 

be updated and written out of the SPE 503 after each use. 
Meters and budgets are common examples of this. Expiration 
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dates cannot be used effectively to prevent substitution of the 
previous copy of a budget UDE 1200. To secure these frequently 
updated items, a transaction tag is generated and included in the 
encrypted item each time that item is updated. A list of all VDE 
5 item IDs and the current transaction tag for each item is 

maintained as part of the secure database 610. 

Figure 24 shows an example of a user data element 
("UDE") 1200 provided by the preferred embodiment. As shown 

10 in Figure 24, UDE 1200 in the preferred embodiment includes a 

public header 802, a private header 804, and a data area 1206. 
The layout for each of these user data elements 1200 is generally 
defined by an SGML data definition contained within a DTD 
1108 associated with one or more load modules 1100 that operate 

15 on the UDE 1200. 

UDEs 1200 are preferably encrypted using a site specific 
key once they are loaded into a site. This site-specific key masks 
a validation tag that may be derived from a cryptographically 
20 strong pseudo-random sequence by the SPE 503 and updated 

each time the record is written back to the secure database 610. 
This technique provides reasonable assurance that the UDE 1200 
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has not been tampered with nor substituted when it is requested 
by the system for the next use. 

Meters and budgets are perhaps among the most common 
5 data structures in VDE 100. They are used to count and record 

events, and also to limit events. The data structures for each 
meter and budget are determined by the content provider or a 
distributor/redistributor authorized to change the information. 
Meters and budgets, however, generally have common 
10 information stored in a common header format (e.g., user ED, site 

ID and related identification information). 



The content provider or distributor/redistributor may 
specify data structures for each meter and budget TIDE. 
15 Although these data structures vary depending upon the 

particular application, some are more common than others. The 
following table lists some of the more commonly occurring data 
structures for METER and BUDGET methods: 



20 
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Field type 


Format 


Typical Use 


Description or Use 


Ascending Use 
Counter 


byte, short, long 
or unsigned 
versions of the 
same widths 


, Meter/Budget 


Ascending count of use 


Descending Use 
Counter 


byte, short, lon§ 
or unsigned 
versions of the 
same widths 


, Budget 


Descending count of 
permitted use; eg., 
remaining budget. 


Counter/Limit 


2, 4 or 8 byte 
integer split int 
two related byte 
or words 


Meter/Budget 

) 

8 


usage limits since a sp 
time; generally used in 

aam BhJbM «b Mm _i A _n_ ii mm mm ^ 

compound meter (lata 
structures. 


Bitmap 


Array bytes 


Meter/Budget 


Bit indicator of use or 
ownership. 


Wide bitmap 


Array of bytes 


Meter/Budget 


Indicator of use or 
ownership that may ag 
with time. 


Last Use Date 


time t 


Meter/Budget 


Date of last use. 


Start Date 


time t 


Budget 


Date of first allowable 


Expiration Date 


time t 


Meter/Budget 


Expiration Date. 


Last Audit Date 


time t 


Meter/Budget 


Date of last audit. 


Next Audit Date 


time t 


Meter/Budget 


Date of next required a 


Auditor 


VDE ID 


Meter/Budget 


VDE ID of authorized 
auditor. 



15 

The information in the table above is not complete or 
comprehensive, but rather is intended to show some examples of 
types of information that may be stored in meter and budget 
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related data structures. The actual structure of particular 
meters and budgets is determined by one or more DTDs 1108 
associated with the load modules 1100 that create and 
manipulate the data structure. A list of data types permitted by 
the DTD interpreter 590 in VDE 100 is extensible by properly 
authorized parties. 
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Figure 25 shows an example of one particularly 
advantageous kind of UDE 1200 data area 1206. This data area 
1206 defines a "map" that may be used to record usage 
information. For example, a meter method 1000 may maintain 
one or more "usage map" data areas 1206. The usage map may 
be a "usage bit map" in the sense that it stores one or more bits of 
information (i.e., a single or multi-dimensional bit image) 
corresponding to each of several types or categories of usage. 
Usage maps are an efficient means for referencing prior usage. 
For example, a usage map data area may be used by a meter 
method 1000 to record all applicable portions of information 
content that the user has paid to use, thus supporting a very 
efficient and flexible means for allowing subsequent user usage of 
the same portions of the information content. This may enable 
certain VDE related security functions such as "contiguousness," 
"logical relatedness," randomization of usage, and other usage 
types. Usage maps may be analyzed for other usage patterns 
(e.g., quantity discounting, or for enabling a user to reaccess 
information content for which the user previously paid for 
unlimited usage). 

The "usage map" concept provided by the preferred 
embodiment may be tied to the concept of "atomic elements." In 
the preferred embodiment, usage of an object 300 may be 
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metered in terms of "atomic elements." In the preferred 
embodiment, an "atomic element" in the metering context defines 
a unit of usage that is "sufficiently significant" to be recorded in a 
meter. The definition of what constitutes an "atomic element" is 
determined by the creator of an object 300. For instance, a "byte" 
of information content contained in an object 300 could be defined 
as an "atomic element," or a record of a database could be defined 
as an "atomic element," or each chapter of an electronically 
published book could be defined as an "atomic element." 

An object 300 can have multiple sets of overlapping atomic 
elements. For example, an access to any database in a plurality 
of databases may be defined as an "atomic element." 
Simultaneously, an access to any record, field of records, sectors 
of informations, and/or bytes contained in any of the plurality of 
databases might also be defined as an "atomic element." In an 
electronically published newspaper, each hundred words of an 
article could be defined as an "atomic element," while articles of 
more than a certain length could be defined as another set of 
"atomic elements." Some portions of a newspaper (e.g., 
advertisements, the classified section, etc.) might not be mapped 
into an atomic element. 

The preferred embodiment provides an essentially 
unbounded ability for the object creator to define atomic element 

441 



WO 96/27155 



PCT/US96/02303 



types. Such atomic element definitions may be very flexible to 
accommodate a wide variety of different content usage. Some 
examples of atomic element types supported by the preferred 
embodiment include bytes, records, files, sectors, objects, a 
quantity of bytes, contiguous or relatively contiguous bytes (or 
other predefined unit types), logically related bytes containing 
content that has some logical relationship by topic, location or 
other user specifiable logic of relationship, etc. Content creators 
preferably may flexibly define other types of atomic elements. 

The preferred embodiment of the present invention 
provides EVENT methods to provide a mapping between usage 
events and atomic elements. Generally, there may be an EVENT 
method for each different set of atomic elements defined for an 
object 300. In many cases, an object 300 will have at least one 
type of atomic element for metering relating to billing, and at 
least one other atomic element type for non-billing related 
metering (e.g., used to, for example, detect fraud, bill advertisers, 
and/or collect data on end user usage activities). 

In the preferred embodiment, each EVENT method in a 
usage related context performs two functions: (1) it maps an 
accessed event into a set of zero or more atomic elements, and (2) 
it provides information to one or more METER methods for 
metering object usage. The definition used to define this 
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mapping between access events and atomic elements may be in 
the form of a mathematical definition, a table, a load module, etc. 
When an EVENT method maps an access request into "zero" 
atomic elements, a user accessed event is not mapped into any 
atomic element based on the particular atomic element definition 
that applies. This can be, for example, the object owner is not 
interested in metering usage based on such accesses (e.g., 
because the object owner deems such accesses to be insignificant 
from a metering standpoint). 

A "usage map" may employ a "bit map image" for storage of 
usage history information in a highly efficient manner. 
Individual storage elements in a usage map may correspond to 
atomic elements. Different elements within a usage map may 
correspond to different atomic elements (e.g., one map element 
may correspond to number of bytes read, another map element 
may correspond to whether or not a particular chapter was 
opened, and yet another map element may correspond to some 
other usage event). 

One of the characteristics of a usage map provided by the 
preferred embodiment of the present invention is that the 
significance of a map element is specified, at least in part, by the 
position of the element within the usage map. Thus, in a usage 
map provided by the preferred embodiment, the information 
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indicated or encoded by a map element is a function of its position 
(either physically or logically) within the map structure. As one 
simple example, a usage map for a twelve-chapter novel could 
consist of twelve elements, one for each chapter of the novel. 
When the user opens the first chapter, one or more bits within 
the element corresponding to the first chapter could be changed 
in value (e.g., set to "one"). In this simple example where the 
owner of the content object containing the novel was interested 
only in metering which chapters had been opened by the user, 
the usage map element corresponding to a chapter could be set to 
"one" the first time the user opened that corresponding chapter, 
and could remain "one" no matter how many additional times the 
user opened the chapter. The object owner or other interested 
VDE participant would be able to rapidly and efficiently tell 
which chapters) had been opened by the user simply by 
examining the compact usage map to determine which elements 
were set to "one." 

Suppose that the content object owner wanted to know how 
many times the user had opened each chapter of the novel. In 
this case, the usage map might comprise, for a twelve-chapter 
novel, twelve elements each of which has a one-to-one 
correspondence with a different one of the twelve chapters of the 
novel. Each time a user opens a particular chapter, the 
corresponding METER method might increment the value 
contained in the corresponding visage map element. In this way, 
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an account could be readily maintained for each of the chapters of 
the novel. 

The position of elements within a usage map may encode a 
multi-variable function. For example, the elements within a 
usage map may be arranged in a two-dimensional array as shown 
in Figure 25B. Different array coordinates could correspond to 
independent variables such as, for example, atomic elements and 
time. Suppose, as an example, that a content object owner 
distributes an object containing a collection of audio recordings. 
Assume further that the content object owner wants to track the 
number of times the user listens to each recording within the 
collection, and also wants to track usage based on month of the 
year. Thus, assume that the content object owner wishes to know 
how many times the user during the month of January listened 
to each of the recordings on a recording-by-recording basis, 
similarly wants to know this same information for the month of 
February, March, etc. In this case, the usage map (see Figure 
25B) might be defined as a two-dimensional array of elements. 
One dimension of the array might encode audio recording 
number. The other dimension of the array might encode month 
of the year. During the month of January, the corresponding 
METER method would increment elements in the array in the 
"January" column of the array, selecting which element to 
increment as a function of recording number. When January 
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comes to an end, the METER method might cease writing into 
the array elements in the January column, and instead write 
values into a further set of February array elements — once again 
selecting the particular array element in this column as a 
function of recording number. This concept may be extended to N 
dimensions encoding N different variables. 

Usage map meters are thus an efficient means for 
referencing prior usage. They may be used to enable certain 
VDE related security functions such as testing for contiguousness 
(including relative contiguousness), logical relatedness (including 
relative logical relatedness), usage randomization, and other 
usage patterns. For example, the degree or character of the 
"randomness" of content usage by a user might serve as a 
potential indicator of attempts to circumvent VDE content budget 
limitations. A user or groups of users might employ multiple 
sessions to extract content in a manner which does not violate 
contiguousness, logical relatedness or quantity limitations, but 
which nevertheless enables reconstruction of a material portion 
or all of a given, valuable unit of content. Usage maps can be 
analyzed to determine other patterns of usage for pricing such as, 
for example, quantity discounting after usage of a certain 
quantity of any or certain atomic units, or for enabling a user to 
reaccess an object for which the user previously paid for 
unlimited accesses (or unlimited accesses over a certain time 
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duration). Other useful analyses might include discounting for a 
given atomic unit for a plurality of uses. 

A further example of a map meter includes storing a record 
of all applicable atomic elements that the user has paid to use (or 
alternatively, has been metered as having used, though payment 
may not yet have been required or made). Such a usage map 
would support a very efficient and flexible way to allow 
subsequent user usage of the same atomic elements. 

A further usage map could be maintained to detect 
fraudulent usage of the same object. For example, the object 
might be stored in such a way that sequential access of long 
blocks should never occur. A METER method could then record 
all applicable atomic elements accesses during, for example, any 
specified increment of time, such as ten minutes, an hour, a day, 
a month, a year, or other time duration). The usage map could be 
analyzed at the end of the specified time increment to check for 
an excessively long contiguous set of accessed blocks, and/or could 
be analyzed at the initiation of each access to applicable atomic 
elements. After each time duration based analysis, if no 
fraudulent use is detected, the usage map could be cleared (or 
partially cleared) and the mapping process could begin in whole 
or in part anew. If a fraudulent use pattern is suspected or 
detected, that information might be recorded and the use of the 



447 



object could be halted. For example, the user might be required 
to contact a content provider who might then further analyze the 
usage information to deter min e whether or not further access 
should be permitted. 

Figure 25c shows a particular type of "wide bit map" usage 
record 1206 wherein each entry in the usage record corresponds 
to usage during a particular time period (e.g., current month 
usage, last month's visage, usage in the month before last, etc.). 
The usage record shown thus comprises an array of "flags" or 
fields 1206, each element in the array being used to indicate 
usage in a different time period in this particular example. When 
a time period ends, all elements 1206 in the array may be shifted 
one position, and thus usage information (or the purchase of user 
access rights) over a series of time periods can be reflected by a 
series of successive array elements. In the specific example 
shown in Figure 25c, the entire wide array 1206 is shifted by one 
array position each month, with the oldest array element being 
deleted and the new array element being "turned" in a new array 
map corresponding to the current time period. In this example, 
record 1302 tracks usage access rights and/or other usage related 
activities during the present calendar month as well for the five 
immediately prior calendar months. Corresponding billing 
and/or billing method 406 may inspect the map, determine usage 
as related to billing and/or security monitoring for current usage 
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based on a formula that employs the usage data stored in the 
record, and updates the wide record to indicate the applicable 
array elements for which usage occurred or the like. A wide bit 
map may also be used for many other purposes such as 
maintaining an element by element count of usage, or the 
contiguousness ? relatedness, etc. function described above, or 
some combination of functionality. 

Audit trail maps may be generated at any frequency 
determined by control, meter, budget and billing methods and 
load modules associated with those methods. Audit trails have a 
similar structure to meters and budgets and they may contain 
user specific information in addition to information about the 
usage event that caused them to be created. Lake meters and 
budgets, audit trails have a dynamic format that is defined by the 
content provider or their authorized designee, and share the 
basic element types for meters and budgets shown in the table 
above. In addition to these types, the following table lists some 
examples of other significant data fields that may be found in 
audit trails: 



Field type 


Format 


Typical Use 


Description of Use 


Use Event ID 


unsigned long 


Meter/Budget/ 


Event ID that started a processing 






Bfflinj? 


sequence. 


Internal 


unsigned long 


Meter/Budget/ 


Transaction number to help detect 


Sequence 




Billing 


audits that have been tampered 


Number 






with. 
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Field type 


Format 


Typical Use 


Description of Use 


Atomic 
Elements) 
& Object ID 


Unsigned 
integer* s) of 
appropriate 


Meter/Billing 


Atomic element! s J and ID of object 
that was used. 


Personal User 
Information 


Character or 
other 

information 


Budget/Billing 


Personal information about user. 


Use Date/Time 


time_t 


Meter/Budget/ 
Billinp 


Date/time of use. 


Site ID/User 
ID 


VDE ID 


Meter/Budget/ 
Billing 


VDE ID of user. 



Audit trail records may be automatically combined into 
single records to conserve header space. The combination process 
may, for example, occur under control of a load module that 
creates individual audit trail records. 

Permissions Record Overview 

Figure 16 also shows that PERCs 808 may be stored as 
part of secure database 610. Permissions records (TERCs") 808 
are at the highest level of the data driven control hierarchy 
provided by the preferred embodiment of VDE 100. Basically, 
there is at least one PERC 808 that corresponds to each 
information and/or transactional content distributed by VDE 100. 
Thus, at least one PERC 808 exists for each VDE object 300 in 
the preferred embodiment. Some objects may have multiple 
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corresponding PERCs 808. PERC 808 controls how access and/or 
manipulation permissions are distributed and/or how content 
and/or other information may otherwise be used. PERC 808 also 
specifies the "rights" of each VDE participant in and to the 
content and/or other information. 

In the preferred embodiment, no end user may use or 
access a VDE object unless a permissions record 808 has been 
delivered to the end user. As discussed above, a PERC 808 may 
be delivered as part of a traveling object 860 or it may be 
delivered separately (for example, within an administrative 
object). An electronic appliance 600 may not access an object 
unless a corresponding PERC 808 is present, and may only use 
the object and related information as permitted by the control 
structures contained within the PERC. 

Briefly, the PERC 808 stores information concerning the 
methods, method options, decryption keys and rights with respect 
to a corresponding VDE object 300. 

PERC 808 includes control structures that define high 
level categories or classifications of operations. These high level 
categories are referred to as "rights." The "right" control 
structures, in turn, provide internal control structures that 
reference "methods" 1000. The internal structure of preferred 
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embodiment PERC 808 organizes the "methods" that are 
required to perform each allowable operation on an object or 
associated control structure (including operations performed on 
the PERC itself). For example, PERC 808 contains decryption 
keys for the object, and usage of the keys is controlled by the 
methods that are required by the PERC for performing 
operations associated with the exercise of a "right." 

PERC 808 for an object is typically created when the object 
is created, and future substantive modifications of a PERC, if 
allowed, are controlled by methods associated with operations 
using the distribution right(s) defined by the same (or different) 
PERC. 

Figure 22 shows the internal structures present in an 
example of a PERC 808 provided by the preferred embodiment. 
All of the structures shown represent (or reference) collections of 
methods required to process a corresponding object in some 
specific way. PERCs 808 are organized as a hierarchical 
structure, and the basic elements of the hierarchy are as follows: 
"rights" records 906 

"control sets" 914 

"required method" records 920 and 
"required method options" 924. 
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There are other elements that may be included in a PERC 
808 hierarchy that describe rules and the rule options to support 
the negotiation of rule sets and control information for smart 
objects and for the protection of a user's personal information by 
a privacy filter. These alternate elements may include: 

optional rights records 

optional control sets 

optional method records 

permitted rights records 

permitted rights control sets 

permitted method records 

required DTD descriptions 

optional DTD descriptions 

permitted DTD descriptions 
These alternate fields can control other processes that may, in 
part, base negotiations or decisions regarding their operation on 
the contents of these fields. Rights negotiation, smart object 
control information, and related processes can use these fields for 
more precise control of their operation. 

The PERC 808 shown in Figure 26 includes a PERC 
header 900, a CSO ("control set 0") 902, private body keys 904, 
and one or more rights sub-records 906. Control set 0 902 in the 
preferred embodiment contains information that is common to 
one or more "rights" associated with an object 300. For example, 
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a particular "event" method or methods might be the same for 
usage rights, extraction rights and/or other rights. In that case, 
"control set 0" 902 may reference this event that is common 
across multiple "rights." The provision of "control set 0" 902 is 
actually an optimization, since it would be possible to store 
different instances of a commonly-used event within each of 
plural "rights" records 906 of a PERC 808. 

Each rights record 906 defines a different "right" 
corresponding to an object. A "right" record 906 is the highest 
level of organization present in PERC 808. There can be several 
different rights in a PERC 808. A "right" represents a major 
functional partitioning desired by a participant of the basic 
architecture of VDE 100. For example, the right to use an object 
and the right to distribute rights to use an object are major 
functional groupings within VDE 100. Some examples of possible 
rights include access to content, permission to distribute rights to 
access content, the ability to read and process audit trails related 
to content and/or control structures, the right to perform 
transactions that may or may not be related to content and/or 
related control structures (such as banking transactions, catalog 
purchases, the collection of taxes, EDI transactions, and such), 
and the ability to change some or all of the internal structure of 
PERCs created for distribution to other users. PERC 808 
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cont ains a rights record 906 for each type of right to object 
access/use the PERC grants. 

Normally, for VDE end users, the most frequently granted 
right is a usage right. Other types of rights include the 
"extraction right," the "audit right" for accessing audit trail 
information of end users, and a "distribution right" to distribute 
an object. Each of these different types of rights may be 
embodied in a different rights record 906 for alternatively, 
different PERCs 808 corresponding to an object may be used to 
grant different rights). 

Each rights record 906 includes a rights record header 908, 
a CSR ("control set for right") 910, one or more "right keys" 912, 
and one or more "control sets" 914. Each "rights" record 906 
contains one or more control sets 914 that are either required or 
selectable options to control an object in the exercise of that 
"right." Thus, at the next level, inside of a "right" 906, are control 
sets 914. Control sets 914, in turn, each includes a control set 
header 916, a control method 918, and one or more required 
methods records 920. Required methods records 920, in turn, 
each includes a required method header 922 and one or more 
required method options 924. 
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Control sets 914 exist in two types in VDE 100: common 
required control sets which are given designations "control set 0" 
or "control set for right," and a set of control set options. "Control 
set 0" 902 contains a list of required methods that are common to 
all control set options, so that the common required methods do 
not have to be duplicated in each control set option. A "control 
set for right" ("CSR") 910 contains a similar list for control sets 
within a given right. "Control set 0" and any "control sets for 
rights" are thus, as mentioned above, optimizations; the same 
functionality for the control sets can be accomplished by listing 
all the common required methods in each control set option and 
omitting "control set 0" and any "control sets for rights." 

One of the control set options, "control set 0" and the 
appropriate "control set for right" together form a complete 
control set necessary to exercise a right. 

Each control set option contains a list of required methods 
1000 and represents a different way the right may be exercised. 
Only one of the possible complete control sets 914 is used at any 
one time to exercise a right in the preferred embodiment. 

Each control set 914 contains as many required methods 
records 920 as necessary to satisfy all of the requirements of the 
creators and/or distributors for the exercise of a right. Multiple 
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ways a right may be exercised, or multiple control sets that 
govern how a given right is exercised, are both supported. As an 
example, a single control set 914 might require multiple meter 
and budget methods for reading the object's content, and also 
require different meter and budget methods for printing an 
object's content. Both reading and printing an object's content 
can be controlled in a single control set 914. 

Alternatively, two different control set options could 
support reading an object's content by using one control set 
option to support metering and budgeting the number of bytes 
read, and the other control set option to support metering and 
budgeting the number of paragraphs read. One or the other of 
these options would be active at a time. 

Typically, each control set 914 will reference a set of 
related methods, and thus different control sets can offer a 
different set of method options. For example, one control set 914 
may represent one distinct kind of metering methodology, and 
another control set may represent another, entirely different 
distinct metering methodology. 

At the next level inside a control set 914 are the required 
methods records 920. Methods records 920 contain or reference 
methods 1000 in the preferred embodiment. Methods 1000 are a 
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collection of "events," references to load modules associated with 
these events, static data, and references to a secure database 610 
for automatic retrieval of any other separately deliverable data 
elements that may be required for processing events (e.g., UDEs). 
A control set 914 contains a list of required methods that must be 
used to exercise a specific right (i.e., process events associated 
with a right). A required method record 920 listed in a control set 
914 indicates that a method must exist to exercise the right that 
the control set supports. The required methods may reference 
'load modules" 1100 to be discussed below. Briefly, load modules 
1100 are pieces of executable code that may be used to carry out 
required methods. 

Each control set 914 may have a control method record 918 
as one of its required methods. The referenced control method 
may define the relationships between some or all of the various 
methods 1000 defined by a control set 906. For example, a 
control method may indicate which required methods are 
functionally grouped together to process particular events, and 
the order for processing the required methods. Thus, a control 
method may specify that required method referenced by record 
920(a)(l)(i) is the first to be called and then its output is to go to 
required method referenced by record 920(a)(l)(ii) and so oh. In 
this way, a meter method may be tied to one or more billing 
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methods and then the billing methods may be individually tied to 
different budget methods, etc. 

Required method records 920 specify one or more required 
method options 924. Required method options are the lowest 
level of control structure in a preferred embodiment PERC 808. 
By parameterizing the required methods and specifying the 
required method options 924 independently of the required 
methods, it becomes possible to reuse required methods in many 
different circumstances. 

For example, a required method record 920 may indicate 
that an actual budget method ED must be chosen from the list of 
budget method IDs in the required method option list for that 
required method. Required method record 920 in this case does 
not contain any method IDs for information about the type of 
method required, it only indicates that a method is required. 
Required method option 924 contains the method ED of the 
method to be used if this required method option is selected. As a 
further optimization, an actual method ED may be stored if only 
one option exists for a specific required method. This allows the 
size of this data structure to be decreased. 

PERC 808 also contains the fundamental decryption keys 
for an object 300, and any other keys used with "rights" (for 
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encoding and/or decoding audit trails, for example). It may 
contain the keys for the object content or keys to decrypt portions 
of the object that contain other keys that then can be used to 
decrypt the content of the object. Usage of the keys is controlled 
by the control sets 914 in the same "right" 906 within PERC 808. 

In more detail, Figure 26 shows PERC 808 as including 
private body keys 904, and right keys 912. Private body keys 904 
are used to decrypt information contained within a private body 
806 of a corresponding VDE object 300. Such information may 
include, for example, methods 1000, load modules 1100 and/or 
UDEs 1200, for example. Right keys 912 are keys used to 
exercise a right in the preferred embodiment. Such right keys 
912 may include, for example, decryption keys that enable a 
method specified by PERC 808 to decrypt content for release by a 
VDE node to an end user. These right keys 912 are, in the 
preferred embodiment, unique to an object 300. Their usage is 
preferably controlled by budgets in the preferred embodiment. 

Detailed Example of a PERC 808 

Figures 26A and 26B show one example of a preferred 
embodiment PERC 808. In this example, PERC header 900 
includes: 

a site record number 926, 
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a field 928 specifying the length of the private body 
key block, 

a field 930 specifying the length of the PERC, 
an expiration date/time field 932 specifying the 

expiration date and/or time for the PERC, 
a last modification date/time field 934 specifying the 

last date and/or time the PERC 808 was 

modified, 

the original distributor ID field 936 that specifies 
who originally distributed the PERC and/or 
corresponding object, 

a last distributor field 938 that specifies who was the 
last distributor of the PERC and/or the object, 

an object ID field 940 identifying the corresponding 
VDE object 300, 

a field 942 that specifies the class and/or type of 
PERC and/or the instance ID for the record 
class to differentiate the PERCs of the same 
type that may differ in their particulars, 

a field 944 specifying the number of "rights" sub- 
records 906 within the PERC, and 

a validation tag 948. 
The PERC 808 shown in Figures 26a, 26b also has private body 
keys stored in a private body key block 950. 
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This PERC 808 includes a control set 0 sub-record 914 (0) 
that may be used commonly by all of rights 906 within the PERC. 
This control set 0 record 914(0) may include the following fields: 
a length field 952 specifying the length of the control 
set 0 record 

a field 954 specifying the number of required method 

records 920 within the control set 
an access tag field 956 specifying an access tag to 

control modification of the record and 
one or more required method records 920. 
Each required method record 920, in turn may include: 

a length field 958 specifying the length of the 

required method record 
a field 960 specifying the number of method option 

records within the required method record 920 
an access tag field 962 specifying an access tag to 

control modification of the record and 
one or more method option records 924. 
Each method option sub-record 924 may include: 

a length field 964 specifying the length of the method 

option record 
a length field 966 specifying the length of the data 

area (if any) corresponding to the method 

option record 
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a method ED field 968 specifying a method ID (e.g., 

type/owner/class/instance) 
a correlation tag field 970 specifying a correlation 

tag for correlating with the method specified in 

field 968 

an access tag field 972 specifying an access tag to 

control modification of this record 
a method-specific attributes field 974 
a data area 976 and 

a check value field 978 for validation purposes 



In this example of PERC 808 also includes one or more 
rights records 906, and an overall check value field 980. Figure 
23b is an example of one of right records 906 shown in Figure 
16a. In this particular example, rights record 906a includes a 
rights record header 908 comprising: 

a length field 982 specifying the length of the rights 

key block 912 
a length field 984 specifying the length of the rights 
record 908 

an expiration date/time field 986 specifying the 
expiration date and/or time for the rights 
record 

a right ID field 988 identifying a right 
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a number field 990 specifying the number of control 
sets 914 within the rights record 906, and 

an access tag field 992 specifying an access tag to 
control modification of the right record. 

This example of rights record 906 includes: 
a control set for this right (CSR) 910 
a rights key block 912 
one or more control sets 914, and 
a check value field 994. 



Object Registry 

Referring once again to Figure 16, secure database 610 
provides data structures that support a "lookup" mechanism for 
"registered" objects. This "lookup" mechanism permits electronic 
appliance 600 to associate, in a secure way, VDE objects 300 with 
PERCs 808, methods 1000 and load modules 1100. In the 
preferred embodiment, this lookup mechanism is based in part on 
data structures contained within object registry 450. 

In one embodiment, object registry 450 includes the 
following tables: 

• an object registration table 460; 

• a subject table 462; 

a User Rights Table CURT) 464; 
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• an Administrative Event Log 442; 

• a shipping table 444; and 

• a receiving table 446. 

Object registry 460 in the example embodiment is a 
database of information concerning registered VDE objects 300 
and the rights of users and user groups with regard to those 
objects. When electronic appliance 600 receives an object 300 
containing a new budget or load module 1100, the electronic 
appliance usually needs to add the information contained by the 
object to secure database 610. Moreover, when any new VDE 
object 300 arrives at an electronic appliance 600, the electronic 
appliance must "register" the object within object registry 450 so 
that it can be accessed. The lists and records for a new object 300 
are built in the preferred embodiment when the object is 
"registered" by the electronic appliance 600. The information for 
the object may be obtained from the object's encrypted private 
header, object body, and encrypted name services record. This 
information may be extracted or derived from the object 300 by 
SPE 503, and then stored within secure database 610 as 
encrypted records. 

In one embodiment, object registration table 460 includes 
information identifying objects within object storage (repository) 
728. These VDE objects 300 stored within object storage 728 are 
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not, in the example embodiment, necessarily part of secure 
database 610 since the objects typically incorporate their own 
security (as necessary and required) and are maintained using 
different mechanisms than the ones used to maintain the secure 
database. Even though VDE objects 300 may not strictly be part 
of secure database 610, object registry 450 (and in particular, 
object registration table 460) refers to the objects and thus 
"incoiporates them by reference" into the secure database. In the 
preferred embodiment, an electronic appliance 600 may be 
disabled from using any VDE object 300 that has not been 
appropriately registered with a corresponding registration record 
stored within object registration table 460. 

Subject table 462 in the example embodiment establishes 
correspondence between objects referred to by object registration 
table 460 and users (or groups of users) of electronic appliance 
600. Subject table 462 provides many of the attributes of an 
access control list ("ACL"), as will be explained below. 

User rights table 464 in the example embodiment provides 
permissioning and other information specific to particular users 
or groups of users and object combinations set forth in subject 
table 462. In the example embodiment, permissions records 808 
(also shown in Figure 16 and being stored within secure database 
610) may provide a universe of permissioning for a particular 
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object-user combination. Records within user rights table 464 
may specify a sub-set of this permissiordng universe based on, for 
example, choices made by users during interaction at time of 
object registration. 

Administrative event log 442, shipping table 444, and 
receiving table 446 provide information about receipts and 
deliveries of VDE objects 300. These data structures keep track 
of administrative objects sent or received by electronic appliance 
600 including, for example, the purpose and actions of the 
administrative objects in summary and detailed form. Briefly, 
shipping table 444 incudes a shipping record for each 
administrative object sent (or scheduled to be sent) by electronic 
appliance 600 to another VDE participant. Receiving table 446 
in the preferred embodiment includes a receiving record for each 
administrative object received (or scheduled to be received) by 
electronic appliance 600. Administrative event log 442 includes 
an event log record for each shipped and each received 
administrative object, and may include details concerning each 
distinct event specified by received administrative objects. 

Adminis trative Object Shipping and Receiving 

Figure 27 is an example of a detailed format for a shipping 
table 444. In the preferred embodiment, shipping table 444 
includes a header 444A and any number of shipping records 445. 
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Header 444A includes information used to maintain shipping 
table 444. Each shipping record 445 within shipping table 444 
provides details concerning a shipping event (i.e., either a 
completed shipment of an administrative object to another VDE 
participant, or a scheduled shipment of an administrative object). 

In the example embodiment of the secure database 610, 
shipping table header 444A may include a site record number 
444A(1), a user (or group) ID 444A(2), a series of reference fields 
444A(3)-444A(6), validation tags 444A(7)-444A(8), and a check 
value field 444A(9). The fields 444A(3)-444A(6) reference certain 
recent IDs that designate lists of shipping records 445 within 
shipping table 444. For example, field 444A(3) may reference to a 
"first" shipping record representing a completed outgoing 
shipment of an administrative object, and field 444A(4) may 
reference to a 'last" shipping record representing a completed 
outgoing shipment of an administrative object. In this example, 
"first" and "last" may, if desired, refer to time or order of 
shipment as one example. Similarly, fields 444A(5) and 444A(6) 
may reference to "first" and "last" shipping records for scheduled 
outgoing shipments. Validation tag 444A(7) may provide 
validation from a name services record within name services 
record table 452 associated with the user (group) ID in the 
header. This permits access from the shipping record back to the 
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name services record that describes the sender of the object 
described by the shipping records. Validation tag 444A(8) 
provides validation for a "first" outgoing shipping record 
referenced by one or more of pointers 444A(3)-444A(6). Other 
validation tags may be provided for validation of scheduled 
shipping record(s). 

Shipping record 444(1) shown includes a site record 
number 445(1XA). It also includes first and last scheduled 
shipment date/times 445(1)(B), 445(1)(C) providing a window of 
time used for sched ulin g administrative object shipments. Field 
445(1)(D) may specify an actual date/time of a completed 
shipment of an administrative object. Field 445(1)(E) provides an 
ID of an administrative object shipped or to be shipped, and thus 
identifies which administrative object within object storage 728 
pertains to this particular shipping record. A reference field 
445f 1)(G) references a name services record within name services 
record table 452 specifying the actual or intended recipient of the 
administrative object shipped or to be shipped. This information 
within name services record table 452 may, for example, provide 
routing information sufficient to permit outgoing administrative 
objects manager 754 shown in Figure 12 to inform object switch 
734 to ship the administrative object to the intended recipient. A 
field 445(1)(H) may specify (e.g., using a series of bit flags) the 
purpose of the administrative object shipment, and a field 
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445(1)(I) may specify the status of the shipment. Reference fields 
445(1)(J), 445(1)(K) may reference "previous" and "next" shipping 
records 445 in a linked list (in the preferred embodiment, there 
may be two linked lists, one for completed shipping records and 
the other for scheduled shipping records). Fields 445(1 XL) - 
445(1)(P) may provide validation tags respectively from header 
444A, to a record within administrative event log 442 pointed to 
by pointer 445(1)(F); to the name services record referenced by 
field 445(1)(G); from the previous record referenced by 445(1)(J); 
and to the next record referenced by field 445(1)(K). A check 
value field 445(1)(Q) may be used for validating shipping record 
445. 



Figure 28 shows an example of one possible detailed format 
for a receiving table 446. In one embodiment, receiving table 446 
has a structure that is similar to the structure of the shipping 
table 444 shown in Figure 27. Thus, for example, receiving table 
446 may include a header 446a and a plurality of receiving 
records 447, each receiving record including details about a 
particular reception or scheduled reception of an administrative 
object. Receiving table 446 may include two linked lists, one for 
completed receptions and another for schedule receptions. 
Receiving table records 447 may each reference an entry within 
name services record table 452 specifying an administrative 
object sender, and may each point to an entry within 
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administrative event log 442. Receiving records 447 may also 
include additional details about scheduled and/or completed 
reception (e.g., scheduled or actual date/time of reception, 
purpose of reception and status of reception), and they may each 
include validation tags for validating references to other secure 
database records. 

Figure 29 shows an example of a detailed format for an 
administrative event log 442. In the preferred embodiment, 
administrative event log 442 includes an event log record 
442(1) . . . 442(N) for each shipped administrative object and for 
each received administrative object. Each administrative event 
log record may include a header 443a and from 1 to N sub-records 
442(J)(1) . . . 442(J)(N). In the preferred embodiment, header 
443a may include a site record number field 443A(1), a record 
length field 443A(2), an administrative object ID field 443A(3), a 
field 443A(4) specifying a number of events, a validation tag 
443 A( 5) from shipping table 444 or receiving table 446, and a 
check sum field 443A(6). The number of events specified in field 
443 A(4) corresponds to the number of sub-records 442(J)(1) . . . 
442(J)(N) within the administrative event log record 442(J). 
Each of these sub-records specifies information about a particular 
"event" affected or corresponding to the administrative object 
specified within field 443(A)(3). Administrative events are 
retained in the administrative event log 442 to permit the 
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reconstruction (and preparation for construction or processing) of 
the administrative objects that have been sent from or received 
by the system. This permits lost administrative objects to be 
reconstructed at a later time. 

Each sub-record may include a sub-record length field 
442(J)(l)(a), a data area length field 442(J)(l)(b), an event ID 
field 442(J)(l)(c), a record type field 442(J)(l)(d), a record ID field 
442(J)(l)(e), a data area field 442(J)(l)(f), and a check value field 
442f J)(l)(g). The data area 442(J)(l)(f) may be used to indicate 
which information within secure database 610 is affected by the 
event specified in the event ID field 442(J)(l)(c), or what new 
secure database item(s) were added, and may also specify the 
outcome of the event. 

The object registration table 460 in the preferred 
embodiment includes a record corresponding to each VDE object 
300 within object storage (repository) 728. When a new object 
arrives or is detected (e.g., by redirector 684), a preferred 
embodiment electronic appliance 600 "registers" the object by 
creating an appropriate object registration record and storing it 
in the object registration table 460. In the preferred embodiment, 
the object registration table stores information that is user- 
independent, and depends only on the objects that are registered 
at a given VDE electronic appliance 600. Registration activities 



472 



WO 96/27155 



PCT/US96/02303 



are typically managed by a REGISTER method associated with 
an object. 

In the example, subject table 462 associates users (or 
groups of users) with registered objects. The example subject 
table 462 performs the function of an access control list by 
specifying which users are authorized to access which registered 
VDE objects 300. 

As described above, secure database 610 stores at least one 
PERC 808 corresponding to each registered VDE object 300. 
PERCS 808 specify a set of rights that may be exercised to use or 
access the corresponding VDE object 300. The preferred 
embodiment allows user to "customize" their access rights by 
selecting a subset of rights authorized by a corresponding PERC 
808 and/or by specifying parameters or choices that correspond to 
some or all of the rights granted by PERC 808. These user 
choices are set forth in a user rights table 464 in the preferred 
embodiment. User rights table (URT) 464 includes URT records, 
each of which corresponds to a user (or group of users). Each of 
these URT records specifies user choices for a corresponding VDE 
object 300. These user choices may, either independently or in 
combination with a PERC 808, reference one or more methods 
1000 for exercising the rights granted to the user by the PERC 
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808 in a way specified by the choices contained within the URT 
record. 

Figure 30 shows an example of how these various tables 
may interact with one another to provide a secure database 
lookup mechanism. Figure 30 shows object registration table 460 
as having a plurality of object registration records 460(1), 460(2), 
. . These records correspond to VDE objects 300(1), 300(2), . . . 
stored within object repository 728. Figure 31 shows an example 
format for an object registration record 460 provided by the 
preferred embodiment. Object registration record 460(N) may 
include the following fields: 

site record number field 466(1) 

object type field 466(2) 

creator ID field 466(3) 

object ID field 466(4) 

a reference field 466(5) that references subject 

table 462 
an attribute field 466(6) 
a minimum registration interval field 466(7) 
a tag 466(8) to a subject table record, and 
a check value field 466(9). 

The site record number field 466(1) specifies the site record 
number for this object registration record 460(N). In one 
embodiment of secure database 610, each record stored within 
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the secure database is identified by a site record number. This 
site record number may be used as part of a database lookup 
process in order to keep track of all of the records within the 
secure database 610. 

Object type field 466(2) may specify the type of registered 
VDE object 300 (e.g., a content object, an administrative object, 
etc.). 

Creator ID field 466(3) in the example may identify the 
creator of the corresponding VDE object 300. 

Object ID field 466(4) in the example uniquely identifies 
the registered VDE object 300. 

Reference field 466(5) in the preferred embodiment 
identifies a record within the subject table 462. Through use of 
this reference, electronic appliance 600 may determine all users 
(or user groups) listed in subject table 462 authorized to access 
the corresponding VDE object 300. Tag 466(8) is used to validate 
that the subject table records accessed using field 466(5) is the 
proper record to be used with the object registration record 
460(N). 
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Attribute field 466(6) may store one or more attributes or 
attribute flags corresponding to VDE object 300. 

Minimum registration interval field 466(7) may specify 
how often the end user may re-register as a user of the VDE * 
object 300 with a clearinghouse service, VDE administrator, or 
VDE provider. One reason to prevent frequent re-registration is 
to foreclose users from reusing budget quantities in traveling 
objects until a specified amount of time has elapsed. The 
yrnniTTurm registration interval field 466(7) may be left unused 
when the object owner does not wish to restrict re-registration. 

Check value field 466(9) contains validation information 
used for detecting corruption or modification of record 460(N) to 
ensure security and integrity of the record. In the preferred 
embodiment, many or all of the fields within record 460(N) (as 
with other records within the secure database 610) may be fully 
or partially encrypted and/or contain fields that are stored 
redundantly in each record (once in unencrypted form and once 
in encrypted form). Encrypted and unencrypted versions of the 
same fields may be cross checked at various times to detect 
corruption or modification of the records. 

As mentioned above, reference field 466(5) references 
subject table 462, and in particular, references one or more 
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user/object records 460(M) within the subject table. Figure 32 
shows an example of a format for a user/object record 462(M) 
provided by the example. Record 462(M) may include a header 
468 and a subject record portion 470. Header 468 may include a 
field 468(6) referencing a "first" subject record 470 contained 
within the subject registration table 462. This "first" subject 
record 470(1) may, in turn, include a reference field 470(5) that 
references a "next" subject record 470(2) within the subject 
registration table 462, and so on. This "linked list" structure 
permits a single object registration record 460(N) to reference to 
from one to N subject records 470. 

Subject registration table header 468 in the example 
includes a site record number field 468(1) that may uniquely 
identify the header as a record within secure database 610. 
Header 468 may also include a creator ID field 468(2) that may 
be a copy of the content of the object registration table creator ID 
field 466(3). Similarly, subject registration table header 468 may 
include an object ID field 468(5) that may be a copy of object ID 
field 466(4) within object registration table 460. These fields 
468(2), 468(5) make user/object registration records explicitly 
correspond to particular VDE objects 300. 

Header 468 may also include a tag 468(7) that permits 
validation. In one example arrangement, the tag 468(7) within 
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the user/object registration header 468 may be the same as the 
tag 466(8) within the object registration record 460(N) that points 
to the user/object registration header. Correspondence between 
these tags 468(7) and 466(8) permits validation that the object 
registration record and user/object registration header match up. 

User/object header 468 also includes an original distributor 
ID field 468(3) indicating the original distributor of the 
corresponding VDE object 300, and the last distributor ID field 
468(4) that indicates the last distributor within the chain of 
handling of the object prior to its receipt by electronic appliance 
600. 

Header 468 also includes a tag 468(8) allowing validation 
between the header and the "first" subject record 470(1) which 
field 468(6) references 

Subject record 470(1) includes a site record number 472(1), 
a user (or user group) ID field 472(2), a user (or user group) 
attributes field 472(3), a field 472(4) referencing user rights table 
464, a field 472(5) that references to the "next" subject record 
470(2) (if there is one), a tag 472(6) used to validate with the 
header tag 468(8), a tag 472(7) used to validate with a 
corresponding tag in the user rights table record referenced by 
field 472(4), a tag 472(9) used to validate with a tag in the "next" 
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subject record referenced to by field 472(5) and a check value field 
472(9). 

User or user group ID 472(2) identifies a user or a user 
•* group authorized to use the object identified in field 468(5). 

Thus, the fields 468(5) and 472(2) together form the heart of the 
access control list provided by subject table 462. User attributes 
field 472(3) may specify attributes pertaining to vise/access to 
object 300 by the user or user group specified in fields 472(2). 
Any number of different users or user groups may be added to 
the access control list (each with a different set of attributes 
472(3)) by providing additional subject records 470 in the "linked 
list" structure. 

Subject record reference field 472(4) references one or more 
records within user rights table 464. Figure 33 shows an 
example of a preferred format for a user rights table record 
464(k). User rights record 464(k) may include a URT header 474, 
a record rights header 476, and a set of user choice records 478. 
URT header 474 may include a site record number field, a field 
474(2) specifying the number of rights records within the URT 
record 464(k), a field 474(3) referencing a "first" rights record 
(i.e., to rights record header 476), a tag 474(4) used to validate 
the lookup from the subject table 462, a tag 474(5) used to 
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validate the lookup to the rights record header 476, and a check 
value field 474(6). 

Rights record header 476 in the preferred embodiment may 
include site record number field 476(1), a right ID field 476(2), a 
field 476(3) referencing the "next" rights record 476(2), a field 
476(4) referencing a first set of user choice records 478(1), a tag 
476(5) to allow validation with URT header tag 474(5), a tag 
476(6) to allow validation with a user choice record tag 478(6), 
and a check value field 476(7). Right ID field 476(2) may, for 
example, specify the type of right conveyed by the rights record 
476(e.g., right to use, right to distribute, right to read, right to 
audit, etc.). 

The one or more user choice records 478 referenced by 
rights record header 476 sets forth the user choices 
corresponding to access and/or use of the corresponding VDE 
object 300. There will typically be a rights record 476 for each 
right authorized to the corresponding user or user group. These 
rights govern use of the VDE object 300 by that user or user 
group. For instance, the user may have an "access" right, and an 
"extraction" right, but not a "copy" right. Other rights controlled 
by rights record 476 (which is derived from PERC 808 using a 
REGISTER method in the preferred embodiment) include 
distribution rights, audit rights, and pricing rights. When an 
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object 300 is registered with the electronic appliance 600 and is 
registered with a particular user or user group, the user may be 
permitted to select among various visage methods set forth in 
PERC 808. For instance, a VDE object 300 might have two 
required meter methodologies: one for billing purposes, and one 
for accumulating data concerning the promotional materials used 
by the user. The user might be given the choice of a variety of 
meter/billing methods, such as: payment by VISA or 
MasterCard; choosing between billing based upon the quantity of 
material retrieved from an information database, based on the 
time of use, and/or both. The user might be offered a discount on 
time and/or quantity billing if he is willing to allow certain details 
concerning his retrieval of content to be provided to third parties 
(e.g., for demographic purposes). At the time of registration of an 
object and/or user for the object, the user would be asked to select 
a particular meter methodology as the "active metering method" 
for the first acquired meter. A VDE distributor might narrow the 
universe of available choices for the user to a subset of the 
original selection array stipulated by PERC 808. These user 
selection and configuration settings are stored within user choice 
records 480(1), 480(2), 480(N). The user choice records need not 
be explicitly set forth within user rights table 464; instead, it is 
possible for user choice records 480 to refer (e.g., by site reference 
number) to particular VDE methods and/or information 
parameterizing those methods. Such reference by user choice 
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records 480 to method 1000 should be validated by validation 
tags contained within the user choice records. Thus, user choice 
records 480 in the preferred embodiment may select one or more 
methods 1000 for use with the corresponding VDE object 300 (as 
is shown in Figure 27). These user choice records 480 may 
themselves fully define the methods 1000 and other information 
used to build appropriate components assemblies 690 for 
implementing the methods. Alternatively, the user/object record 
462 used to reference the user rights record 464 may also 
reference the PERC 808 corresponding to VDE object 300 to 
provide additional information needed to build the component 
assembly 690 and/or otherwise access the VDE object 300. For 
example, PERC 808 may be accessed to obtain MDEs 1202 
pert ainin g to the selected methods, private body and/or rights 
keys for decrypting and/or encrypting object contents, and may 
also be used to provide a checking capability ensuring that the 
user rights record conveys only those rights authorized by a 
current authorization embodied within a PERC. 

In one embodiment provided by the present invention, a 
conventional database engine may be used to store and organize 
secure database 610, and the encryption layers discussed above 
may be "on top of* the conventional database structure. 
However, if such a conventional database engine is unable to 
organize the records in secure database 610 and support the 
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security considerations outlined above, then electronic appliance 
600 may maintain separate indexing structures in encrypted 
form. These separate indexing structures can be maintained by 
SPE 503. This embodiment would require SPE 503 to decrypt 
the index and search decrypted index blocks to find appropriate 
"site record IDs a or other pointers. SPE 503 might then request 
the indicated record from the conventional database engine. If 
the record ED cannot be checked against a record list, SPE 503 
might be required to ask for the data file itself so it can retrieve 
the desired record. SPE 503 would then perform appropriate 
authentication to ensure that the file has not been tampered with 
and that the proper block is returned. SPE 503 should not 
simply pass the index to the conventional database engine 
(unless the database engine is itself secure) since this would 
allow an incorrect record to be swapped for the requested one. 

Figure 34 is an example of how the site record numbers 
described above may be used to access the various data 
structures within secure database 610. In this example, secure 
database 610 further includes a site record table 482 that stores a 
plurality of site record numbers. Site record table 482 may store 
what is in effect a "master list" of all records within secure 
database 610. These site record numbers stored by site record 
table 482 permit any record within secure database 610 to be 
accessed. Thus, some of the site records within site record table 
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482 may index records with an object registration table 460, 
other site record numbers within the site record table may index 
records within the user/object table 462, still other site record 
numbers within the site record table may access records within 
URT 464, and still other site record numbers within the site 
record table may access PERCs 808. In addition, each of method 
cores 1000' may also include a site record number so they may be 
accessed by site record table 482. 

Figure 34A shows an example of a site record 482(j) within 
site record table 482. Site record 482(j) may include a field 484(1) 
indicating the type of record, a field 484(2) indicating the owner 
or creator of the record, a "class " field 484(3) and an "instance" 
field 484(4) providing additional information about the record to 
which the site record 482(j) points; a specific descriptor field 
484(5) indicating some specific descriptor (e.g., object ID) 
associated with the record; an identification 484(6) of the table or 
other data structure which the site record references; a reference 
and/or offset within that data structure indicating where the 
record begins; a validation tag 484(8) for validating the record 
being looked up, and a check value field 484(9). Fields 484(6) and 
484(7) together may provide the mechanism by which the record 
referenced to by the site record 484(j) is actually physically 
located within the secure database 610. 
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Updating Secure Database 610 

Figure 35 show an example of a process 1150 which can be 
used by a clearinghouse, VDE administrator or other VDE 
participant to update the secure database 610 maintained by an 
end user's electronic appliance 600. For example, the process 
1500 shown in Figure 35 might be used to collect "audit trail" 
records within secure database 610 and/or provide new budgets 
and permissions (e.g., PERCs 808) in response to an end user's 
request. 

Typically, the end user's electronic appliance 600 may 
initiate communications with a clearinghouse (Block 1152). This 
contact may, for example, be established automatically or in 
response to a user command. It may be initiated across the 
electronic highway 108, or across other communications networks 
such as a LAN, WAN, two-way cable or using portable media 
exchange between electronic appliances. The process of 
exchanging administrative information need not occur in a single 
"on line" session, but could instead occur over time based on a 
number of different one-way and/or two-way communications 
over the same or different communications means. However, the 
process 1150 shown in Figure 35 is a specific example where the 
end user's electronic appliance 600 and the other VDE 
participant (e.g., a clearinghouse) establish a two-way real-time 
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interactive communications exchange across a telephone line, 
network, electronic highway 108, etc. 

The end user's electronic appliance 600 generally contacts 
a particular VDE administrator or dearinghouse. The identity of 
the particular clearinghouse is based on the VDE object 300 the 
user wishes to access or has already accessed. For example, 
suppose the user has already accessed a particular VDE object 
300 and has ran out of budget for further access. The user could 
issue a request which will cause her electronic appliance 600 to 
automatically contact the VDE administrator, distributor and/or 
financial clearinghouse that has responsibility for that particular 
object. The identity of the appropriate VDE participants to 
contact is provided in the example by information within UDEs 
1200, MDEs 1202, the Object Registration Table 460 and/or 
Subject Table 462, for example. Electronic appliance 600 may 
have to contact multiple VDE participants (e.g., to distribute 
audit records to one participant, obtain additional budgets or 
other permissions from another participant, etc.). The contact 
1152 may in one example be scheduled in accordance with the 
Figure 27 Shipping Table 444 and the Figure 29 Administrative 
Event Log 442. 

Once contact is established, the end user's electronic 
appliance and the clearinghouse typically authenticate one 
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another and agree on a session key to use for the real-time 
information exchange (Block 1154). Once a secure connection is 
established, the end user's electronic appliance may determine 
(e.g., based on Shipping Table 444) whether it has any 
administrative object(s) containing audit information that it is 
supposed to send to the clearinghouse (decision Block 1156). 
Audit information pert ainin g to several VDE objects 300 may be 
placed within the same administrative object for transmission, or 
different administrative objects may contain audit information 
about different objects. Assuming the end user's electronic 
appliance has at least one such administrative object to send to 
this particular clearinghouse ("yes" exit to decision Block 1156), 
the electronic appliance sends that administrative object to the 
clearinghouse via the now-established secure real-time 
communications (Block 1158). In one specific example, a single 
administrative object may be sent an administrative object 
containing audit information pertaining to multiple VDE objects, 
with the audit information for each different object compromising 
a separate "event" within the administrative object. 

The clearinghouse may receive the administrative object 
and process its contents to determine whether the contents are 
"valid" and "legitimate." For example, the clearinghouse may 
analyze the contained audit information to determine whether it 
indicates misuse of the applicable VDE object 300. The 
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clearinghouse may, as a result of this analysis, may generate one 
or more responsive administrative objects that it then sends to 
the end user's electronic appliance 600 (Block 1160). The end 
user's electronic appliance 600 may process events that update 
its secure database 610 and/or SPU 500 contents based on the 
administrative object received (Block 1162). For example, if the 
audit information received by the clearinghouse is legitimate, 
then the clearinghouse may send an administrative object to the 
end user's electronic appliance 600 requesting the electronic 
appliance to delete and/or compress the audit information that 
has been transferred. Alternatively or in addition, the 
clearinghouse may request additional information from the end- 
user electronic appliance 600 at this stage (e.g., retransmission of 
certain information that was corrupted during the initial 
transmission, tr ansmis sion of additional information not earlier 
transmitted, etc.). If the clearinghouse detects misuse based on 
the received audit information, it may transmit an 
administrative object that revokes or otherwise modifies the end 
user's right to further access the associated VDE objects 300. 

The clearinghouse may, in addition or alternatively, send 
an administrative object to the end user's electronic appliance 
600 that instructs the electronic appliance to display one or more 
messages to the user. These messages may inform the user 
about certain conditions and/or they may request additional 
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information from the user. For example, the message may 
instruct the end user to contact the clearinghouse directly by 
telephone or otherwise to resolve an indicated problem, enter a 
PIN, or it may instruct the user to contact a new service company 
to re-register the associated VDE object. Alternatively, the 
message may tell the end user that she needs to acquire new 
usage permissions for the object, and may inform the user of cost, 
status and other associated information. 

During the same or different communications exchange, 
the same or different clearinghouse may handle the end user's 
request for additional budget and/or permission pertaining to 
VDE object 300. For example, the end user's electronic appliance 
600 may (e.g., in response to a user input request to access a 
particular VDE object 300) send an administrative object to the 
clearinghouse requesting budgets and/or other permissions 
allowing access (Block 1164). As mentioned above, such requests 
may be transmitted in the form of one or more administrative 
objects, such as, for example, a single administrative object 
having multiple "events" associated with multiple requested 
budgets and/or other permissions for the same or different VDE 
objects 300. The clearinghouse may upon receipt of such a 
request, check the end user's credit, financial records, business 
agreements and/or audit histories to determine whether the 
requested budgets and/or permissions should be given. The 
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clearinghouse may, based on this analysis > send one or more 
responsive administrative objects which cause the end user's 
electronic appliance 600 to update its secure database in 
response (Block 1166, 1168). This updating might, for example, 
comprise replacing an expired PERC 808 with a fresh one, 
modifying a PERC to provide additional (or lesser) rights, etc. 
Steps 1164-1168 may be repeated multiple times in the same or 
different communications session to provide further updates to 
the end user's secure database 610. 

Figure 36 shows an example of how a new record or 
element may be inserted into secure database 610. The load 
process 1070 shown in Figure 35 checks each data element or 
item as it is loaded to ensure that it has not been tampered with, 
replaced or substituted. In the process 1070 shown in Figure 35, 
the first step that is performed is to check to see if the current 
user of electronic appliance 600 is authorized to insert the item 
into secure database 610 (block 1072). This test may involve, in 
the preferred embodiment, loading (or using already loaded) 
appropriate methods 1000 and other data structures such as 
UDEs 1200 into an SPE 503, which then authenticates user 
authorization to make the change to secure database 610 (block 
1074). If the user is approved as being authorized to make the 
change to secure database 610, then SPE 503 may check the 
integrity of the element to be added to the secure database by 
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decrypting it (block 1076) and determining whether it has become 
damaged or corrupted (block 1078). The element is checked to 
ensure that it decrypts properly using a predetermined 
management file key, and the check value may be validated. In 
addition, the public and private header ID tags (if present) may 
be compared to ensure that the proper element has been provided 
and had not been substituted, and the unique element tag ID 
compared against the predetermined element tag. If any of these 
tests fail, the element may be automatically rejected, error 
corrected, etc. Assuming the element is found to have integrity, 
SPE 503 may re-encrypt the information (block 1080) using a 
new key for example (see Figure 37 discussion below). In the 
same process step an appropriate tag is preferably provided so 
that the information becomes encrypted within a security 
wrapper having appropriate tags contained therein (block 1082). 
SPE 503 may retain appropriate tag information so that it can 
later validate or otherwise authenticate the item when it is again 
read from secure database 610 (block 1084). The now-secure 
element within its security wrapper may then be stored within 
secure database 610. 

Figure 37 shows an example of a process 1050 used in the 
preferred embodiment database to securely access an item stored 
in secure database 610. In the preferred embodiment, SPE 503 
first accesses and reads in the item from secure database 610 
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records. SPE 503 reads this information from secure database 
610 in encrypted form, and may "unwrap" it (block 1052) by 
decrypting it (block 1053) based on access keys internally stored 
within the protected memory of an SPU 500. In the preferred 
embodiment, this "unwrap" process 1052 involves sending blocks 
of information to encrypt/decrypt engine 522 along with a 
management file key and other necessary information needed to 
decrypt. Decrypt engine 522 may return "plaintext" information 
that SPE 503 then checks to ensure that the security of the object 
has not been breached and that the object is the proper object to 
be used (block 1054). SPE 503 may then check all correlation 
and access tags to ensure that the read-in element has not been 
substituted and to guard against other security threats (block 
1054). Part of this "checking" process involves checking the tags 
obtained from the secure database 610 with tags contained 
within the secure memory or an SPU 500 (block 1056). These 
tags stored within SPU 500 may be accessed from SPU protected 
memory (block 1056) and used to check further the now- 
unwrapped object. Assuming this "checking" process 1054 does 
not reveal any improprieties (and block 1052 also indicates that 
the object has not become corrupted or otherwise damaged), SPE 
503 may then access or otherwise use the item (block 1058). 
Once use of the item is completed, SPE 503 may need to store the 
item back into secure database 610 if it has changed. If the item 
has changed, SPE 503 will send the item in its changed form to 
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encrypt/decrypt engine 522 for encryption (block 1060), providing 
the appropriate necessary information to the encrypt/decrypt 
engine (e.g., the appropriate same or different management file 
key and data) so that the object is appropriately encrypted. A 
unique, new tag and/or encryption key may be used at this stage 
to uniquely tag and/or encrypt the item security wrapper (block 
1062; see also detailed Figure 37 discussion below). SPE 503 
may retain a copy of the key and/or tag within a protected 
memory of SPU 500 (block 1064) so that the SPE can decrypt and 
validate the object when it is again read from secure database 
610. 

The keys to decrypt secure database 610 records are, in the 
preferred embodiment, maintained solely within the protected 
memory of an SPU 500. Each index or record update that leaves 
the SPU 500 may be time stamped, and then encrypted with a 
unique key that is determined by the SPE 503. For example, a 
key identification number may be placed "in plain view" at the 
front of the records of secure database 610 so the SPE 503 can 
determine which key to use the next time the record is retrieved. 
SPE 503 can maintain the site ID of the record or index, the key 
identification number associated with it, and the actual keys in 
the list internal to the SPE. At some point, this internal list may 
fill up. At this point, SPE 503 may call a maintenance routine 
that re-encrypts items within secure database 610 containing 
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changed information. Some or all of the items within the data 
structure containing changed information may be read in, 
decrypted, and then re-encrypted with the same key. These 
items may then be issued the same key identification number. 
The items may then be written out of SPE 503 back into secure 
database 610. SPE 503 may then clear the internal list of item 
IDs and corresponding key identification numbers. It may then 
begin again the process of assigning a different key and a new 
key identification number to each new or changed item. By using 
this process, SPE 503 can protect the data structures (including 
the indexes) of secure database 610 against substitution of old 
items and against substitution of indexes for current items. This 
process also allows SPE 503 to validate retrieved item IDs 
against the encrypted list of expected IDs, 

Figure 38 is a flowchart showing this process in more 
detail. Whenever a secure database 610 item is updated or 
modified, a new encryption key can be generated for the updated 
item. Encryption using a new key is performed to add security 
and to prevent misuse of backup copies of secure database 610 
records. The new encryption key for each updated secure 
database 610 record may be stored in SPU 500 secure memory 
with an indication of the secure database record or record(s) to 
which it applies. 
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SPE 503 may generate a new encryption/decryption key for 
each new item it is going to store within secure database 610 
(block 1086). SPE 503 may use this new key to encrypt the 
record prior to storing it in the secure database (block 1088). 
SPE 503 make sure that it retains the key so that it can later 
read and decrypt the record. Such decryption keys are, in the 
preferred embodiment, maintained within protected non-volatile 
memory (e.g., NVRAM 534b) within SPU 500. Since this 
protected memory has a limited size, there may not be enough 
room within the protected memory to store a new key. This 
condition is tested for by decision block 1090 in the preferred 
embodiment. If there is not enough room in memory for the new 
key (or some other event such as the number of keys stored in the 
memory exceeding a predetermined number, a timer has expired, 
etc.), then the preferred embodiment handles the situation by re- 
encrypting other records with secure database 610 with the same 
new key in order to reduce the number of (or change) 
encryption/decryption keys in use. Thus, one or more secure 
database 610 items may be read from the secure database (block 
1092), and decrypted using the old key(s) used to encrypt them 
the last time they were stored. In the preferred embodiment, one 
or more "old keys" are selected, and all secure database items 
encrypted using the old key(s) are read and decrypted. These 
records may now be re-encrypted using the new key that was 
generated at block 1086 for the new record (block 1094). The old 
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key(s) used to decrypt the other record(s) may now be removed 
from the SPU protected memory (block 1096), and the new key 
stored in its place (block 1097). The old key(s) cannot be removed 
from secure memory by block 1096 unless SPE 503 is assured 
that all records within the secure database 610 that were 
encrypted using the old key(s) have been read by block 1092 and 
re-encrypted by block 1904 using the new key. All records 
encrypted (or re-encrypted) using the new key may now be stored 
in secure database 610 (block 1098). If decision block 1090 
determines there is room within the SPU 500 protected memory 
to store the new key, then the operations of blocks 1092, 1094, 
1096 are not needed and SPE 503 may instead simply store the 
new key within the protected memory (block 1097) and store the 
new encrypted records into secure database 610 (block 1098). 

The security of secure database 610 files may be further 
improved by segmenting the records into "compartments." 
Different encryption/decryption keys may be used to protect 
different "compartments." This strategy can be used to limit the 
amount of information within secure database 610 that is 
encrypted with a single key. Another technique for increasing 
security of secure database 610 may be to encrypt different 
portions of the same records with different keys so that more 
than one key may be needed to decrypt those records. 
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Backup of Secure Database 610 

Secure database 610 in the preferred embodiment is 
backed up at periodic or other time intervals to protect the 
information the secure database contains. This secure database 
information may be of substantial value to many VDE 
participants. Back ups of secure database 610 should occur 
without significant inconvenience to the user, and should not 
breach any security. 

The need to back up secure database 610 may be checked 
at power on of electronic appliance 600, when SPE 503 is initially 
invoked, at periodic time intervals, and if "audit roll up" value or 
other summary services information maintained by SPE 503 
exceeds a user set or other threshold, or triggered by criteria 
established by one or more content publishers and/or distributors 
and/or clearinghouse service providers and/or users. The user 
may be prompted to backup if she has failed to do so by or at 
some certain point in time or after a certain duration of time or 
quantity of usage, or the backup may proceed automatically 
without user intervention. 

Referring to Figure 8, backup storage 668 and storage 
media 670 (e.g., magnetic tape) may be used to store backed up 
information. Of course, any non-volatile media (e.g., one or more 
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floppy diskettes, a writable optical diskette, a hard drive, or the 
like) may be used for backup storage 668. 

There are at least two scenarios to backing up secure 
database 610. The first scenario is "site specific," and uses the 
security of SPU 500 to support restoration of the backed up 
information. This first method is used in case of damage to 
secure database 610 due for example to failure of secondary 
storage device 652, inadvertent user damage to the files, or other 
occurrences that may damage or corrupt some or all of secure 
database 610. This first, site specific scenario of back up assumes 
that an SPU 500 still functions properly and is available to 
restore backed up information. 

The second back up scenario assumes that the user's SPU 
500 is no longer operational and needs to be, or has been, 
replaced. This second approach permits an authorized VDE 
administrator or other authorized VDE participant to access the 
stored back up information in order to prevent loss of critical data 
and/or assist the user in recovering from the error. 

Both of these scenarios are provided by the example of 
program control steps performed by ROS 602 shown in Figure 39. 
Figure 39 shows an example back up routine 1250 performed by 
an electronic appliance 600 to back up secure database 610 (and 
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other information) onto back up storage 668. Once a back up has 
been initiated, as discussed above, back up routine 1250 
generates one or more back up keys (block 1252). Back up 
routine 1250 then reads all secure database items, decrypts each 
item using the original key used to encrypt them before they were 
stored in secure database 610 (block 1254). Since SPU 500 is 
typically the only place where the keys for decrypting this 
information within an instance of secure database 610 are stored, 
and since one of the scenarios provided by back up routine 1250 
is that SPU 500 completely failed or is destroyed, back up routine 
1250 performs this reading and decrypting step 1254 so that 
recovery from a backup is not dependent on knowledge of these 
keys within the SPU. Instead, back up routine 1250 encrypts 
each secure database 610 item with a newly generated back up 
key(s) (block 1256) and writes the encrypted item to back up store 
668 (block 1258). This process continues until all items within 
secure database 610 have been read, decrypted, encrypted with a 
newly generated back up key(s), and written to the back up store 
(as tested for by decision block 1260). 

The preferred embodiment also reads the summary 
services audit information stored within the protected memory of 
SPU 500 by SPE summary services manager 560, encrypts this 
information with the newly generated back up key(s), and writes 
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this summary services information to back up store 668 (block 
1262). 

Finally, back up routine 1250 saves the back up key(s) 
generated by block 1252 and used to encrypt in blocks 1256, 1262 
onto back up store 668. It does this in two secure ways in order 
to cover both of the restoration scenarios discussed above. Back 
up routine 1250 may encrypt the back up key(s) (along with other 
information such as the time of back up and other appropriate 
information to identify the back up) with a further key or keys 
such that only SPU 500 can decrypt (block 1264). This encrypted 
information is then written to back up store 668 (block 1264). 
For example, this step may include multiple encryptions using 
one or more public keys with corresponding private keys known 
only to SPU 500. Alternatively, a second back up key generated 
by the SPU 500 and kept only in the SPU may be used for the 
final encryption in place of a public key. Block 1264 preferably 
includes multiple encryption in order to make it more difficult to 
attack the security of the back up by "cracking" the encryption 
used to protect the back up keys. Although block 1262 includes 
encrypted summary services information on the back up, it 
preferably does not include SPU device private keys, shared keys, 
SPU code and other internal security information to prevent this 
information from ever becoming available to users even in 
encrypted form. 
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The information stored by block 1264 is sufficient to allow 
the same SPU 500 that performed (or at least in part performed) 
back up routine 1250 to recover the backed up information. 
However, this information is useless to any device other than 
that same SPU because only that SPU knows the particular keys 
used to protect the back up keys. To cover the other possible 
scenario wherein the SPU 500 fails in a non-recoverable way, 
back up routine 1250 provides an additional step (block 1266) of 
saving the back up key(s) under protection of one or more farther 
set of keys that may be read by an authorized VDE 
administrator. For example, block 1266 may encrypt the back up 
keys with an "download authorization key" received during 
initialization of SPU 500 from a VDE administrator. This 
encrypted version of back up keys is also written to back up store 
668 (block 1266). It can be used to support restoration of the 
back up files in the event of an SPU 500 failure. More 
specifically, a VDE administrator that knows the download 
authorization (or other) keys(s) used by block 1266 may be able to 
recover the back up key(s) in the back up store 668 and proceed 
to restore the backed up secure database 610 to the same or 
different electronic appliance 600. 

In the preferred embodiment, the information saved by 
routine 1250 in back up files can be restored only after receiving 
a back up authorization from an authorized VDE administrator. 
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In most cases, the restoration process will simply be a restoration 
of secure database 610 with some adjustments to account for any 
usage since the back up occurred. This may require the user to 
contact additional providers to transmit audit and billing data 
and receive new budgets to reflect activity since the last back up. 
Current summary services information maintained within SPU 
500 may be compared to the summary services information 
stored on the back up to determine or estimate most recent usage 
activity. 

In case of an SPU 500 failure, an authorized VDE 
administrator must be contacted to both initialize the 
replacement SPU 500 and to decrypt the back up files. These 
processes allow for both SPU failures and upgrades to new SPUs. 
In the case of restoration, the back up files are used to restore the 
necessary information to the user's system. In the case of 
upgrades, the back up files may be used to validate the upgrade 
process. 

The back up files may in some instances be used to 
transfer management information between electronic appliances 
600. However, the preferred embodiment may restrict some or 
all information from being transportable between electronic 
appliances with appropriate authorizations. Some or all of the 
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back up files may be packaged within an administrative object 
and transmitted for analysis, transportation, or other uses. 

As a more detailed example of a need for restoration from 
back up files, suppose an electronic appliance 600 suffers a hard 
disk failure or other accident that wipes out or corrupts part or 
all of the secure database 610, but assume that the SPU 500 is 
still functional. SPU 500 may include all of the information (e.g., 
secret keys and the like) it needs to restore the secure database 
610. However, ROS 602 may prevent secure database restoration 
until a restoration authorization is received from a VDE 
administrator. A restoration authorization may comprise, for 
example, a "secret value" that must match a value expected by 
SPE 503. A VDE administrator may, if desired, only provide this 
restoration authorization after, for example, summary services 
information stored within SPU 500 is transmitted to the 
administrator in an administrative object for analysis. In some 
circumstances, a VDE administrator may require that a copy 
(partial or complete) of the back up files be transmitted to it 
within an administrative object to check for indications of 
fraudulent activities by the user. The restoration process, once 
authorized, may require adjustment of restored budget records 
and the like to reflect activity since the last back up, as 
mentioned above. 
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Figure 40 is an example of program controlled "restore" 
routine 1268 performed by electronic appliance 600 to restore 
secure database 610 based on the back up provided by the 
routine shown in Figure 38/ This restore may be used, for 
example, in the event that an electronic appliance 600 has failed 
but can be recovered or "reinitialized" through contact with a 
VDE administrator for example. Since the preferred embodiment 
does not permit an SPU 500 to restore from backup unless and 
until authorized by a VDE administrator, restore routine 1268 
begins by establishing a secure communication with a VDE 
administrator that can authorize the restore to occur (block 
1270). Once SPU 500 and the VDE administrator authenticate 
one another (part of block 1270), the VDE administrator may 
extract "work in progress" and summary values from the SPU 
500's internal non-volatile memory (block 1272). The VDE 
administrator may use this extracted information to help 
determine, for example, whether there has been a security 
violation, and also permits a failed SPU 500 to effectively "dump" 
its contents to the VDE administrator to permit the VDE 
administrator to handle the contents. The SPU 500 may encrypt 
this information and provide it to the VDE administrator 
packaged in one or more administrative objects. The VDE 
administrator may then request a copy of some or all of the 
current backup of secure database 610 from the SPU 500 (block 
1274). This information may be packaged by SPU 500 into one or 
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more administrative objects, for example, and sent to the VDE 
administrator. Upon receiving the information, the VDE 
administrator may read the summary services audit information 
from the backup volume (i.e., information stored by Figure 38 
block 1262) to determine the summary values and other 
information stored at time of backup. The VDE administrator 
may also determine the time and date the backup was made by 
reading the information stored by Figure 38 block 1264. 

The VDE administrator may at this point restore the 
summary values and other information within SPU 500 based on 
the information obtained by block 1272 and from the backup 
(block 1276). For example, the VDE administrator may reset 
SPU internal summary values and counters so that they are 
consistent with the last backup. These values may be adjusted 
by the VDE administrator based on the "work in progress" 
recovered by block 1272, the amount of time that has passed 
since the backup, etc. The goal may typically be to attempt to 
provide internal SPU values that are equal to what they would 
have been had the failure not occurred. 

The VDE administrator may then authorize SPU 500 to 
recover its secure database 610 from the backup files (block 
1278). This restoration process replaces all secure database 610 
records with the records from the backup. The VDE 
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administrator may adjust these records as needed by passing 
commands to SPU 500 during or after the restoration process. 

The VDE administrator may then compute bills based on 
the recovered values (block 1280), and perform other actions to 
recover from SPU downtime (block 1282). Typically, the goal is to 
bill the user and adjust other VDE 100 values pertaining to the 
failed electronic appliance 600 for usage that occurred 
subsequent to the last backup but prior to the failure. This 
process may involve the VDE administrator obtaining, from other 
VDE participants, reports and other information pertaining to 
usage by the electronic appliance prior to its failure and 
comparing it to the secure database backup to determine which 
usage and other events are not yet accounted for. 

In one alternate embodiment, SPU 500 may have sufficient 
internal, non- volatile memory to allow it to store some or all of 
secure database 610. In this embodiment, the additional memory 
may be provided by additional one or more integrated circuits 
that can be contained within a secure enclosure, such as a 
tamper resistant metal container or some form of a chip pack 
cont ainin g multiple integrated circuit components, and which 
impedes and/or evidences tampering attempts, and/or disables a 
portion or all of SPU 500 or associated critical key and/or other 
control information in the event of tampering. The same back up 



506 



WO 96/27155 



PCT/US96/02303 



routine 1250 shown in Figure 38 may be used to back up this 
type of information, the only difference being that block 1254 
may read the secure database item from the SPU internal 
memory and may not need to decrypt it before encrypting it with 
the back up key(s). 

Event-Driven VDE Processes 

As discussed above, processes provided by/under the 
preferred embodiment rights operating system (ROS) 602 may be 
"event driven." This "event driven" capability facilitates 
integration and extendibility. 

An "event" is a happening at a point in time. Some 
examples of "events" are a user striking a key of a keyboard, 
arrival of a message or an object 300, expiration of a timer, or a 
request from another process. 

In the preferred embodiment, ROS 602 responds to an 
"event" by performing a process in response to the event. ROS 
602 dynamically creates active processes and tasks in response to 
the occurrence of an event. For example, ROS 602 may create 
and begin executing one or more component assemblies 690 for 
performing a process or processes in response to occurrence of an 
event. The active processes and tasks may terminate once ROS 
602 has responded to the event. This ability to dynamically 
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create (and end) tasks in response to events provides great 
flexibility, and also permits limited execution resources such as 
those provided by an SPU 500 to perform a virtually unlimited 
variety of different processes in different contexts. 

Since an "event* may be any type of happening, there are 
an unlimited number of different events. Thus, any attempt to 
categorize events into different types will necessarily be a 
generalization. Keeping this in mind, it is possible to categorize 
events provided/supported by the preferred embodiment into two 
broad categories: 

• user-initiated events; and 

• system-initiated events. 

Generally, "user-initiated" events are happenings 
attributable to a user (or a user application). A common "user- 
initiated" event is a user's request (e.g., by pushing a keyboard 
button, or transparently using redirector 684) to access an object 
300 or other VDE-protected information. 

"System-initiated" events are generally happenings not 
attributable to a user. Examples of system initiated events 
include the expiration of a timer indicating that information 
should be backed to non-volatile memory, receipt of a message 
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from another electronic appliance 600, and a service call 
generated by another process (which may have been started to 
respond to a system-initiated event and/or a user-initiated event). 

ROS 602 provided by the preferred embodiment responds 
to an event by specifying and beginning processes to process the 
event. These processes are, in the preferred embodiment, based 
on methods 1000. Since there are an unlimited number of 
different types of events, the preferred embodiment supports an 
unlimited number of different processes to process events. This 
flexibility is supported by the dynamic creation of component 
assemblies 690 from independently deliverable modules such as 
method cores 1000\ load modules 1100, and data structures such 
as UDEs 1200. Even though any categorization of the unlimited 
potential types of processes supported/provided by the preferred 
embodiment will be a generalization, it is possible to generally 
classify processes as falling within two categories: 

• processes relating to use of VDE protected information; 
and 

• processes relating to VDE administration. 

"Use'and "AdministrativeTrocesses 

"Use" processes relate in some way to use of VDE-protected 
information. Methods 1000 provided by the preferred 
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embodiment may provide processes for creating and maintaining 
a chain of control for use of VDE-protected information. One 
specific example of a "use" type process is processing to permit a 
user to open a VDE object 300 and access its contents. A method 
1000 may provide detailed use-related processes such as, for 
example, releasing content to the user as requested (if 
permitted), and updating meters, budgets, audit trails, etc. Use- 
related processes are often user-initiated, but some use processes 
may be system-initiated. Events that trigger a VDE use-related 
process may be called "use events." 

An "administrative" process helps to keep VDE 100 
working. It provides processing that helps support the 
transaction management "infrastructure" that keeps VDE 100 
running securely and efficiently. Administrative processes may, 
for example, provide processing relating to some aspect of 
creating, modifying and/or destroying VDE-protected data 
structures that establish and maintain VDE's chain of handling 
and control. For example, "administrative" processes may store, 
update, modify or destroy information contained within a VDE 
electronic appliance 600 secure database 610. Administrative 
processes also may provide communications services that 
establish, maintain and support secure communications between 
different VDE electronic appliances 600. Events that trigger 
administrative processes may be called "administrative events." 
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Reciprocal Methods 

Some VDE processes are paired based on the way they 
interact together. One VDE process may "request" processing 
services from another VDE process. The process that requests 
processing services may be called a "request process." The 
"request" constitutes an "event" because it triggers processing by 
the other VDE process in the pair. The VDE process that 
responds to the "request event" may be called a "response 
process." The "request process" and "response process" may be 
called "reciprocal processes." 

The "request event" may comprise, for example, a message 
issued by one VDE node electronic appliance 600 or process for 
certain information. A corresponding "response process" may 
respond to the "request event" by, for example, sending the 
information requested in the message. This response may itself 
constitute a "request event" if it triggers a further VDE "response 
process." For example, receipt of a message in response to an 
earlier-generated request may trigger a "reply process." This 
"reply process" is a special type of "response process" that is 
triggered in response to a "reply" from another "response 
process." There may be any number of "request" and "response" 
process pairs within a given VDE transaction. 
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A "request process" and its paired "response process" may 
be performed on the same VDE electronic appliance 600, or the 
two processes may be performed on different VDE electronic 
appliances. Communication between the two processes in the 
pair may be by way of a secure (VDE-protected) communication, 
an "out of channel" co mmuni cation, or a combination of the two. 

Figures 41a-41d are a set of examples that show how the 
chain of handling and control is enabled using "reciprocal 
methods." A chain of handling and control is constructed, in part, 
using one or more pairs of "reciprocal events" that cooperate in 
request-response manner. Pairs of reciprocal events may be 
managed in the preferred embodiment in one or more "reciprocal 
methods." As mentioned above, a "reciprocal method" is a 
method 1000 that can respond to one or more "reciprocal events." 
Reciprocal methods contain the two halves of a cooperative 
process that may be securely executed at physically and/or 
temporally distant VDE nodes. The reciprocal processes may 
have a flexibly defined information passing protocols and 
information content structure. The reciprocal methods may, in 
fact, be based on the same or different method core 1000' 
operating in the same or different VDE nodes 600. VDE nodes 
600A and 600B shown in Figure 41a may be the same physical 
electronic appliance 600 or may be separate electronic appliances. 
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Figure 41a is an example of the operation of a single pair of 
reciprocal events. In VDE node 600A, method 1000a is 
processing an event that has a request that needs to be processed 
at VDE node 600B. The method 1000a (e.g., based on a 
component assembly 690 including its associated load modules 
1100 and data) that responds to this "request" event is shown in 
Figure 41a as 1450. The process 1450 creates a request (1452) 
and, optionally, some information or data that will be sent to the 
other VDE node 1000b for processing by a process associated 
with the reciprocal event. The request and other information 
may be transmitted by any of the transport mechanisms 
described elsewhere in this disclosure. 

Receipt of the request by VDE node 600b comprises a 
response event at that node. Upon receipt of the request, the 
VDE node 600b may perform a "reciprocal" process 1454 defined 
by the same or different method 1000b to respond to the response 
event. The reciprocal process 1454 may be based on a component 
assembly 690 (e.g., one or more load modules 1100, data, and 
optionally other methods present in the VDE node 600B). 

Figure 41b extends the concepts presented in Figure 41a to 
include a response from VDE node 600B back to VDE node 600A. 
The process starts as described for Figure 41a through the 
receipt and processing of the request event and information 1452 
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by the response process 1454 in VDE node 600B. The response 
process 1454 may, as part of its processing, cooperate with 
another request process (1468) to send a response 1469 back to 
the initiating VDE node 600A. A corresponding reciprocal 
process 1470 provided by method 1000A may respond to and 
process this request event 1469. In this manner, two or more 
VDE nodes 600A, 600B may cooperate and pass configurable 
information and requests between methods 1000A, 1000B 
executing in the nodes. The first and second request-response 
sequences [(1450, 1452, 1454) and (1468, 1469, 1470)] may be 
separated by temporal and spatial distances. For efficiency, the 
request (1468) and response (1454) processes may be based on 
the same method 1000 or they may be implemented as two 
methods in the same or different method core 1000'. A method 
1000 may be parameterized by an "event code" so it may provide 
different behaviors/results for different events, or different 
methods may be provided for different events. 

Figure 41c shows the extension the control mechanism 
described in Figures 41a-41b to three nodes (600A, 600B, 600C). 
Each request-response pair operates in the manner as described 
for Figure 41b, with several pairs linked together to form a chain 
of control and handling between several VDE nodes 600A, 600B, 
600C. This mechanism may be used to extend the chain of 
handling and control to an arbitrary number of VDE nodes using 
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any configuration of nodes. For example, VDE node 600C might 
co mmuni cate directly to VDE node 600A and communicate 
directly to VDE 600B, which in turn communicates with VDE 
node 600A. Alternately, VDE node 600C might communicate 
directly with VDE node 600A, VDE node 600A may communicate 
with VDE node 600B, and VDE node 600B may communicate 
with VDE node 600C. 

A method 1000 may be parameterized with sets of events 
that specify related or cooperative functions. Events may be 
logically grouped by function (e.g., use, distribute), or a set of 
reciprocal events that specify processes that may operate in 
conjunction with each other. Figure 41d illustrates a set of 
"reciprocal events" that support cooperative processing between 
several VDE nodes 102, 106, 112 in a content distribution model 
to support the distribution of budget. The chain of handling and 
control, in this example, is enabled by using a set of "reciprocal 
events" specified within a BUDGET method. Figure 41d is an 
example of how the reciprocal event behavior within an example 
BUDGET method (1510) work in cooperation to establish a chain 
of handling and control between several VDE nodes. The 
example BUDGET method 1510 responds to a "use" event 1478 
by performing a "use" process 1476 that defines the mechanism 
by which processes are budgeted. The BUDGET method 1510 
might, for example, specify a use process 1476 that compares a 
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meter count to a budget value and fail the operation if the meter 
count exceeds the budget value. It might also write an audit trail 
that describes the results of said BUDGET decisions. Budget 
method 1510 may respond to a "distribute" event by performing a 
distribute process 1472 that defines the process and/or control 
information for further distribution of the budget. It may 
respond to a "request" event 1480 by performing a request 
process 1480 that specifies how the user might request use and/or 
distribution rights from a distributor. It may respond to a 
"response" event 1482 by performing a response process 1484 
that specifies the manner in which a distributor would respond to 
requests from other users to whom they have distributed some 
(or all) of their budget t6. It may respond to a "reply" event 1474 
by performing a reply process 1475 that might specify how the 
user should respond to message regranting or denying (more) 
budget. 

Control of event processing, reciprocal events, and then- 
associated methods and method components is provided by 
PERCs 808 in the preferred embodiment. These PERCs (808) 
might reference administrative methods that govern the creation, 
modification, and distribution of the data structures and 
administrative methods that permit access, modification, and 
further distribution of these items. In this way, each link in the 
chain of handling and control might, for example, be able to 
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customize audit information, alter the budget requirements for 
using the content, and/or control further distribution of these 
rights in a manner specified by prior members along the 
distribution chain. 

In the example shown in Figure 4 Id, a distributor at a 
VDE distributor node (106) might request budget from a content 
creator at another node (102). This request may be made in the 
context of a secure VDE communication or it may be passed in an 
"out-of-channel" communication (e.g. a telephone call or letter). 
The creator 102 may decide to grant budget to the distributor 106 
and processes a distribute event (1452 in BUDGET method 1510 
at VDE node 102). A result of processing the distribute event 
within the BUDGET method might be a secure communication 
(1454) between VDE nodes 102 and 106 by which a budget 
granting use and redistribute rights to the distributor 106 may 
be transferred from the creator 102 to the distributor. The 
distributor's VDE node 106 may respond to the receipt of the 
budget information by processing the communication using the 
reply process 1475B of the BUDGET method 1510. The reply 
event processing 1475B might, for example, install a budget and 
PERC 808 within the distributor's VDE 106 node to permit the 
distributor to access content or processes for which access is 
control at least in part by the budget and/or PERC. At some 
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point, the distributor 106 may also desire to use the content to 
which she has been granted rights to access. 

After registering to use the content object, the user 112 
would be required to utilize an array of "use" processes 1476C to, 
for example, open, read, write, and/or close the content object as 
part of the use process. 

Once the distributor 106 has used some or all of her 
budget, she may desire to obtain additional budget. The 
distributor 106 might then initiate a process using the BUDGET 
method request process (1480B). Request process 1480B might 
initiate a communication (1482AB) with the content creator VDE 
node 102 requesting more budget and perhaps providing details 
of the use activity to date (e.g., audit trails). The content creator 
102 processes the 'get more budget' request event 1482AB using 
the response process (1484A) within the creator's BUDGET 
method 1510A. Response process 1484A might, for example, 
make a determination if the use information indicates proper use 
of the content, and/or if the distributor is credit worthy for more 
budget. The BUDGET method response process 1484A might 
also initiate a financial transaction to transfer funds from the 
distributor to pay for said use, or use the distribute process 
1472A to distribute budget to the distributor 106. A response to 
the distributor 106 granting more budget (or denying more 
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budget) might be sent immediately as a response to the request 
communication 1482AB, or it might be sent at a later time as 
part of a separate communication. The response communication, 
upon being received at the distributor's VDE node 106, might be 
processed using the reply process 1475B within the distributor's 
copy of the BUDGET method 1510B. The reply process 1475B 
might then process the additional budget in the same manner as 
described above. 

The chain of handling and control may, in addition to 
posting budget information, also pass control information that 
governs the manner in which said budget may be utilized. For 
example, the control information specified in the above example 
may also contain control information describing the process and 
limits that apply to the distributor's redistribution of the right to 
use the creator's content object. Thus, when the distributor 
responds to a budget request from a user (a communication 
between a user at VDE node 112 to the distributor at VDE node 
106 similar in nature to the one described above between VDE 
nodes 106 and 102) using the distribute process 1472B within the 
distributor's copy of the BUDGET method 1510B, a distribution 
and request/response/reply process similar to the one described 
above might be initiated. 
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Thus, in this example a single method can provide multiple 
dynamic behaviors based on different "triggering" events. For 
example, single BUDGET method 1510 might support any or all 
of the events listed below: 



Event Type 


Event 


Process Description 


"Use" Events 


use budget 


Use budget. 


Request Events 
Processed by User 
Node Request Process 
1480c 


request more budget 


Request more money for budget. 


request audit by auditor #1 


Request that auditor #1 audit the 
budget use. 


request budget deletion 


Request that budget be deleted from 
system. 


request method updated 


Update method used for auditing. 


request to change auditors 


Change from auditor 1 to auditor 2, or 
vice versa. 


request different audit 
interval 


Change time interval between audits. 


request ability to provide 
budget copies 


Request ability to provide copies of a 
budget. 


request ability to 
distribute budget 


Request ability to distribute a budget 
to other users. 


request account status 


Request information on current status 
of an account. 


Request New Method 


Request new method. 


Request Method Update 


Request update of method. 


Request Method Deletion 


Request deletion of method. 


Response Events 
Processed by User 
Node Request Process 
1480C 


receive more budget 


Allocate more monev to budget. 


receive method update 


Update method. 


receive auditor change 


Change from one auditor to another. 


receive change to audit 
interval 


Change interval between audits. 
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Event Type 


Event 


Process Description 




receive budpet deletion 


Delete budget. 




provide audit to auditor #1 


Forward audit information to auditor 
#1. 




provide audit to auditor #2 


Forward audit information to auditor 
#2. 




receive account status 


Provide account status. 


Receive New 


Receive new budget. 




Receive Method Update 


Receive updated information. 
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Send audit information. 


Perform Deletion 


Delete information. 


"Distribute" Events 
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ivequest events 
Processed by 
Distributor Node 
Request Process 
1484B 


lseieie 
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Get New 


Uet new budpet. 


Get More 


viet more lor budget. 
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Get Audited 


Get audit information. 


"Response Events" 
Processed by 
Distributor Node 
Request Process 


Provide New to user 


Provide new budpet to user. 


Provide More to user 


Provide more budpet to user. 


Provide Update to user 


Provided updated budpet to user. 
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Event Type 


Event 


Process Description 




Audit user 


Audit a specified user. 




Delete users method 


Delete method belonging to user. 



Examples of Reciprocal Method Processes 
A. BUDGET 

Figures 42a, 42b, 42c and 42d, respectively, are flowcharts 
of example process control steps performed by a representative 
example of BUDGET method 2250 provided by the preferred 
embodiment. In the preferred embodiment, BUDGET method 
2250 may operate in any of four different modes: 

• use (see Figure 42a) 

♦ administrative request (see Figure 42b) 

♦ administrative response (see Figure 42c) 

• administrative reply (see Figure 42d). 

In general, the "use" mode of BUDGET method 2250 is invoked 
in response to an event relating to the use of an object or its 
content. The "administrative request" mode of BUDGET method 
2250 is invoked by or on behalf of the user in response to some 
user action that requires contact with a VDE financial provider, 
and basically its task is to send an administrative request to the 
VDE financial provider. The "administrative response" mode of 
BUDGET method 2250 is performed at the VDE financial 
provider in response to receipt of an administrative request sent 
from a VDE node to the VDE financial provider by the 
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"administrative request" invocation of BUDGET method 2250 
shown in Figure 42b. The "administrative response" invocation 
of BUDGET method 2250 results in the transmission of an 
administrative object from VDE financial provider to the VDE 
user node. Finally, the "administrative reply" invocation of 
BUDGET method 2250 shown in Figure 42d is performed at the 
user VDE node upon receipt of the administrative object sent by 
the "administrative response" invocation of the method shown in 
Figure 42c. 

In the preferred embodiment, the same BUDGET method 
2250 performs each of the four different step sequences shown in 
Figures 42a-42d. In the preferred embodiment, different event 
codes may be passed to the BUDGET method 2250 to invoke 
these various different modes. Of course, it would be possible to 
use four separate BUDGET methods instead of a single BUDGET 
method with four different "dynamic personalities," but the 
preferred embodiment obtains certain advantages by using the 
same BUDGET method for each of these four types of 
invocations. 

Looking at Figure 42a, the "use" invocation of BUDGET 
method 2250 first primes the Budget Audit Trail (blocks 2252, 
2254). It then obtains the DTD for the Budget UDE, which it 
uses to obtain and read the Budget UDE blocks 2256-2262). 
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BUDGET method 2250 in this "use" invocation may then 
determine whether a Budget Audit date has expired, and 
terminate if it has ("yes" exit to decision block 2264; blocks 2266, 
2268). So long as the Budget Audit date has not expired, the 
method may then update the Budget using the atomic element 
and event counts (and possibly other information) (blocks 2270, 
2272), and may then save a Budget User Audit record in a 
Budget Audit Trail UDE (blocks 2274, 2276) before terminating 
(at terminate point 2278). 

Looking at Figure 42b, the first six steps (blocks 2280- 
2290) may be performed by the user VDE node in response to 
some user action (e.g., request to access new information, request 
for a new budget, etc.). This "administrative request" invocation 
of BUDGET method 2250 may prime an audit trail (blocks 2280, 
2282). The method may then place a request for administrative 
processing of an appropriate Budget onto a request queue (blocks 
v 2284, 2286). Finally, the method may save appropriate audit 
trail information (blocks 2288, 2290). Sometime later, the user 
VDE node may prime a communications audit trail (blocks 2292, 
2294), and may then write a Budget Administrative Request into 
an administrative object (block 2296). This step may obtain 
information from the secure database as needed from such 
sources such as, for example, Budget UDE; Budget Audit Trail 
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UDE(s); and Budget Administrative Request Record(s) (block 
2298). 

Block 2296 may then communicate the administrative 
object to a VDE financial provider, or alternatively, block 2296 
may pass administrative object to a separate communications 
process or method that arranges for such communications to 
occur. If desired, method 2250 may then save a communications 
audit trail (blocks 2300, 2302) before terminating (at termination 
point 2304). 

Figure 42c is a flowchart of an example of process control 
steps performed by the example of BUDGET method 2250 
provided by the preferred embodiment operating in an 
"administrative response" mode. Steps shown in Figure 42c 
would, for example, be performed by a VDE financial provider 
who has received an administrative object containing a Budget 
administrative request as created (and communicated to a VDE 
administrator for example) by Figure 42b (block 2296). 

Upon receiving the administrative object, BUDGET 
method 2250 at the VDE financial provider site may prime a 
budget communications and response audit trail (blocks 2306, 
2308), and may then unpack the administrative object and 
retrieve the budget requests), audit trail(s) and record(s) it 
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contains (block 2310). This information retrieved from the 
administrative object may be written by the VDE financial 
provider into its secure database (block 2312). The VDE financial 
provider may then retrieve the budget request(s) and determine 
the response method it needs to execute to process the request 
(blocks 2314, 2316). BUDGET method 2250 may send the 
event(s) contained in the request record(s) to the appropriate 
response method and may generate response records and 
response requests based on the RESPONSE method (block 2318). 
The process performed by block 2318 may satisfy the budget 
request by writing appropriate new response records into the 
VDE financial provider's secure database (block 2320). BUDGET 
method 2250 may then write these Budget administrative 
response records into an administrative object (blocks 2322, 
2324), which it may then communicate back to the user node that 
initiated the budget request. BUDGET method 2250 may then 
save communications and response processing audit trail 
information into appropriate audit trail UDE(s) (blocks 2326, 
2328) before terminating (at termination point 2330). 

Figure 42d is a flowchart of an example of program control 
steps performed by a representative example of BUDGET method 
2250 operating in an "administrative reply" mode. Steps shown 
in Figure 42d might be performed, for example, by a VDE user 
node upon receipt of an administrative object containing budget- 
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related information. BUDGET method 2250 may first prime a 
Budget administrative and communications audit trail (blocks 
2332, 2334). BUDGET method 2250 may then extract records 
and requests from a received administrative object and write the 
reply record to the VDE secure database (blocks 2336, 2338). The 
VDE user node may then save budget administrative and 
communications audit trail information in an appropriate audit 
trail UDE(s) (blocks 2340, 2341). 

Sometime later, the VDE user node may retrieve the reply 
record from the secure database and determine what method is 
required to process it (blocks 2344, 2346). The VDE user node 
may, optionally, prime an audit trail (blocks 2342, 2343) to record 
the results of the processing of the reply event. The BUDGET 
method 2250 may then send event(s) contained in the reply 
record(s) to the REPLY method, and may generate/update the 
secure database records as necessary to, for example, insert new 
budget records, delete old budget records and/or apply changes to 
budget records (blocks 2348, 2350). BUDGET method 2250 may 
then delete the reply record from the secure data base (blocks 
2352, 2353) before writing the audit trail (if required) (blocks 
2354m 2355) terminating (at terminate point 2356). 
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B. REGISTER 

Figures 43a-43d are flowcharts of an example of program 
control steps performed by a representative example of a 
REGISTER method 2400 provided by the preferred embodiment. 
In this example, the REGISTER method 2400 performs the 
example steps shown in Figure 43a when operating in a ''use" 
mode, performs the example steps shown in Figure 43b when 
operating in an "administrative request" mode, performs the 
steps shown in Figure 43c when operating in an "administrative 
response" mode, and performs the steps shown in Figure 43d 
when operating in an "administrative reply" mode. 

The steps shown in Figure 43a may be, for example, 
performed at a user VDE node in response to some action by or 
on behalf of the user. For example the user may ask to access an 
object that has not yet been (or is not now) properly registered to 
her. In response to such a user request, the REGISTER method 
2400 may prime a Register Audit Trail UDE (blocks 2402, 2404) 
before determining whether the object being requested has 
already been registered (decision block 2406). If the object has 
already been registered ("yes" exit to decision block 2406), the 
REGISTER method may terminate (at termination point 2408). 
If the object is not already registered ("no" exit to decision block 
2406), then REGISTER method 2400 may access the VDE node 
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secure database PERC 808 and/or Register MDE (block 2410). 
REGISTER method 2400 may extract an appropriate Register 
Record Set from this PERC 808 and/or Register MDE (block 
2412), and deter min e whether all of the required elements are 
present that are needed to register the object (decision block 
2414). If some piece(s) is missing ("no" exit to decision block 
2414), REGISTER method 2400 may queue a Register request 
record to a communication manager and then suspend the 
REGISTER method until the queued request is satisfied (blocks 
2416, 2418). Block 2416 may have the effect of communicating a 
register request to a VDE distributor, for example. When the 
request is satisfied and the register request record has been 
received (block 2420), then the test of decision block 2414 is 
satisfied ("yes* exit to decision block 2414), and REGISTER 
method 2400 may proceed. At this stage, the REGISTER method 
2400 may allow the user to select Register options from the set of 
method options allowed by PERC 808 accessed at block 2410 
(block 2422). As one simple example, the PERC 808 may permit 
the user to pay by VISA or MasterCard but not by American 
Express; block 2422 may display a prompt asking the user to 
select between paying using her VISA card and paying using her 
MasterCard (block 2424). The REGISTER method 2400 
preferably validates the user selected registration options and 
requires the user to select different options if the initial user 
options were invalid (block 2426, "no" exit to decision block 2428). 
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Once the user has made all required registration option 
selections and those selections have been validated ("yes" exit to 
decision block 2428), the REGISTER method 2400 may write an 
User Registration Table (URT) corresponding to this object and 
this user which embodies the user registration selections made 
by the user along with other registration information required by 
PERC 808 and/or the Register MDE (blocks 2430, 2432). 
REGISTER method 2400 may then write a Register audit record 
into the secure database (blocks 2432, 2434) before terminating 
(at terminate point 2436). 

Figure 43b shows an example of an "administrative 
request" mode of REGISTER method 2400. This Administrative 
Request Mode may occur on a VDE user system to generate an 
appropriate administrative object for communication to a VDE 
distributor or other appropriate VDE participant requesting 
registration information. Thus, for example, the steps shown in 
Figure 43b may be performed as part of the "queue register 
request record" block 2416 shown in Figure 43a. To make a 
Register administrative request, REGISTER method 2400 may 
first prime a communications audit trail (blocks 2440, 2442), and 
then access the secure database to obtain data about registration 
(block 2444). This secure database access may, for example, 
allow the owner and/or publisher of the object being registered to 
find out demographic, user or other information about the user. 
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As a specific example, suppose that the object being registered is 
a spreadsheet software program. The distributor of the object 
may want to know what other software the user has registered. 
For example, the distributor may be willing to give preferential 
pricing if the user registers a "suite* of multiple software 
products distributed by the same distributor. Thus, the sort of 
information solicited by a "user registration" card enclosed with 
most standard software packages may be solicited and 
automatically obtained by the preferred embodiment at 
registration time. In order to protect the privacy rights of the 
user, REGISTER method 2400 may pass such user-specific data 
through a privacy filter that may be at least in part customized 
by the user so the user can prevent certain information from 
being revealed to the outside world (block 2446). The REGISTER 
method 2400 may write the resulting information along with 
appropriate Register Request information identifying the object 
and other appropriate parameters into an administrative object 
(blocks 2448, 2450). REGISTER method 2400 may then pass this 
administrative object to a communications handler. REGISTER 
method 2400 may then save a communications audit trail (blocks 
2452, 2454) before terminating (at terminate point 2456). 

Figure 43c includes REGISTER method 2400 steps that 
may be performed by a VDE distributor node upon receipt of 
Register Administrative object sent by block 2448, Figure 43b. 
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REGISTER method 2400 in this "administrative response" mode 
may prime appropriate audit trails (blocks 2460, 2462), and then 
may unpack the received administrative object and write the 
associated register requests) configuration information into the 
secure database (blocks 2464, 2466). REGISTER method 2400 
may then retrieve the administrative request from the secure 
database and determine which response method to run to process 
the request (blocks 2468, 2470). If the user fails to provide 
sufficient information to register the object, REGISTER method 
2400 may fail (blocks 2472, 2474). Otherwise, REGISTER 
method 2400 may send event(s) contained in the appropriate 
request record(s) to the appropriate response method, and 
generate and write response records and response requests (e.g., 
PERC(s) and/or UDEs) to the secure database (blocks 2476, 
2478). REGISTER method 2400 may then write the appropriate 
Register administrative response record into an administrative 
object (blocks 2480, 2482). Such information may include, for 
example, one or more replacement PERC(s) 808, methods, 
UDE(s), etc. (block 2482). This enables, for example, a 
distributor to distribute limited right permissions giving users 
only enough information to register an object, and then later, 
upon registration, replacing the limited right permissions with 
wider permissioning scope granting the user more complete 
access to the objects. REGISTER method 2400 may then save 
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the co mmuni cations and response processing audit trail (blocks 
2484, 2486), before terminating (at terminate point 2488). 

Figure 43d shows steps that may be performed by the VDE 
user node upon receipt of the administrative object 
generated/transmitted by Figure 43c block 2480. The steps 
shown in Figure 43d are very similar to those shown in Figure 
42d for the BUDGET method administrative reply process. 

C. AUDIT 

Figures 44a-44c are flowcharts of examples of program 
control steps performed by a representative example of an 
AUDIT method 2520 provided by the preferred embodiment. As 
in the examples above, the AUDIT method 2520 provides three 
different operational modes in this preferred embodiment 
example: Figure 44a shows the steps performed by the AUDIT 
method in an "administrative request" mode; Figure 44b shows 
steps performed by the method in the "administrative response" 
mode; and Figure 44c shows the steps performed by the method 
in an "administrative reply" mode. 

The AUDIT method 2520 operating in the "administrative 
request" mode as shown in Figure 44a is typically performed, for 
example, at a VDE user node based upon some request by or on 
behalf of the user. For example, the user may have requested an 
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audit, or a timer may have expired that initiates communication 
of audit information to a VDE content provider or other VDE 
participant. In the preferred embodiment, different audits of the 
same overall process may be performed by different VDE 
participants. A particular "audit" method 2520 invocation may 
be initiated for any one (or all) of the involved VDE participants. 
Upon invocation of AUDIT method 2520, the method may prime 
an audit administrative audit trail (thus, in the preferred 
embodiment, the audit processing may itself be audited) (blocks 
2522, 2524). The AUDIT method 2520 may then queue a request 
for administrative processing (blocks 2526, 2528), and then may 
save the audit administrative audit trail in the secure database 
(blocks 2530, 2532). Sometime later, AUDIT method 2520 may 
prime a communications audit trail (blocks 2534, 2536), and may 
then write Audit Administrative Request(s) into one or more 
administrative object(s) based on specific UDE, audit trail 
UDE(s), and/or administrative record(s) stored in the secure 
database (blocks 2538, 2540). The AUDIT method 2520 may 
then save appropriate information into the communications audit 
trail (blocks 2542, 2544) before terminating (at terminate point 
2546). 

Figure 44b shows example steps performed by a VDE 
content provider, financial provider or other auditing VDE node 
upon receipt of the administrative object generated and 
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communicated by Figure 44a block 2538. The AUDIT method 
2520 in this "administrative response" mode may first prime an 
Audit co mmunic ations and response audit trail (blocks 2550, 
2552), and may then unpack the received administrative object 
and retrieve its contained Audit request(s) audit trail(s) and 
audit record(s) for storage into the secured database (blocks 2554, 
2556). AUDIT method 2520 may then retrieve the audit 
request(s) from the secure database and determine the response 
method to run to process the request (blocks 2558, 2560). AUDIT 
method 2520 may at this stage send event(s) contained in the 
request record(s) to the appropriate response method, and 
generate response record(s) and requests based on this method 
(blocks 2562, 2564). The processing block 2562 may involve a 
communication to the outside world. 

For example, AUDIT method 2520 at this point could call 
an external process to perform, for example, an electronic funds 
transfer against the riser's bank account or some other bank 
account. The AUDIT administrative response can, if desired, call 
an external process that interfaces VDE to one or more existing 
computer systems. The external process could be passed the 
user's account number, PIN, dollar amount, or any other 
information configured in, or associated with, the VDE audit trail 
being processed. The external process can communicate with 
non-VDE hosts and use the information passed to it as part of 
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these co mmunic ations. For example, the external process could 
generate automated clearinghouse (ACH) records in a file for 
submittal to a bank. This mechanism would provide the ability 
to automatically credit or debit a bank account in any financial 
institution. The same mechanism could be used to communicate 
with the existing credit card (e.g. VISA) network by submitting 
VDE based charges against the charge account. 

Once the appropriate Audit response record(s) have been 
generated, AUDIT method 2520 may write an Audit 
administrative record(s) into an administrative object for 
communication back to the VDE user node that generated the 
Audit request (blocks 2566, 2568). The AUDIT method 2520 may 
then save co mmuni cations and response processing audit 
information in appropriate audit trail(s) (blocks 2570, 2572) 
before terminating (at terminate point 2574). 

Figure 44c shows an example of steps that may be 
performed by the AUDIT method 2520 back at the VDE user 
node upon receipt of the administrative object generated and sent 
by Figure 44b, block 2566. The steps 2580-2599 shown in Figure 
44c are similar to the steps shown in Figure 43d for the 
REGISTER method 2400 in the "administrative reply" mode. 
Briefly, these steps involve receiving and extracting appropriate 
response records from the administrative object (block 2584), and 
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then processing the received information appropriately to update 
secure database records and perform any other necessary actions 
(blocks 2595, 2596). 

Examples of Event-Driven Content-Based Methods 

VDE methods 1000 are designed to provide a very flexible 
and highly modular approach to secure processing. A complete 
VDE process to service a "use event" may typically be constructed 
as a combination of methods 1000. As one example, the typical 
process for reading content or other information from an object 
300 may involve the following methods: 

• an EVENT method 

• a METER method 

• a BILLING method 

• a BUDGET method. 

Figure 45 is an example of a sequential series of methods 
performed by VDE 100 in response to an event. In this example, 
when an event occurs, an EVENT method 402 may "qualify" the 
event to deter min e whether it is significant or not. Not all events 
are significant. For example, if the EVENT method 1000 in a 
control process dictates that usage is to be metered based upon 
number of pages read, then user request "events" for reading less 
than a page of information may be ignored. In another example, 
if a system event represents a request to read a certain number 
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of bytes, and the EVENT method 1000 is part of a control process 
designed to meter paragraphs, then the EVENT method may 
evaluate the read request to determine how many paragraphs 
are represented in the bytes requested. This process may involve 
mapping to "atomic elements" to be discussed in more detail 
below. 

EVENT method 402 filters out events that are not 
significant with regard to the specific control method involved. 
EVENT method 402 may pass on qualified events to a METER 
process 1404, which meters or discards the event based on its 
own particular criteria. 

In addition, the preferred embodiment provides an 
optimization called "precheck," EVENT method/process 402 may 
perform this "precheck* based on metering, billing and budget 
information to determine whether processing based on an event 
will be allowed. Suppose, for example, that the user has already 
exceeded her budget with respect to accessing certain 
information content so that no further access is permitted. 
Although BUDGET method 408 could make this determination, 
records and processes performed by BUDGET method 404 and/or 
BILLING method 406 might have to be "undone" to, for example, 
prevent the user from being charged for an access that was 
actually denied. It may be more efficient to perform a "precheck" 
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within EVENT method 402 so that fewer transactions have to be 
"undone." 

METER method 404 may store an audit record in a meter 
"trail" UDE 1200, for example, and may also record information 
related to the event in a meter UDE 1200. For example, METER 
method 404 may increment or decrement a "meter" value within 
a meter UDE 1200 each time content is accessed. The two 
different data structures (meter UDE and meter trail UDE) may 
be maintained to permit record keeping for reporting purposes to 
be maintained separately from record keeping for internal 
operation purposes, for example. 

Once the event is metered by METER method 404, the 
metered event may be processed by a BILLING method 406. 
BILLING method 406 determines how much budget is consumed 
by the event, and keeps records that are useful for reconciliation 
of meters and budgets. Thus, for example, BILLING method 406 
may read budget information from a budget UDE, record billing 
information in a billing UDE, and write one or more audit records 
in a billing trail UDE. While some billing trail information may 
duplicate meter and/or budget trail information, the billing trail 
information is useful, for example, to allow a content creator 102 
to expect a payment of a certain size, and serve as a 
reconciliation check to reconcile meter trail information sent to 
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creator 102 with budget trail information sent to, for example, an 
independent budget provider. 

BILLING method 406 may then pass the event on to a 
BUDGET method 408. BUDGET method 408 sets limits and 
records transactional information associated with those limits. 
For example, BUDGET method 408 may store budget 
information in a budget UDE, and may store an audit record in a 
budget trail UDE. BUDGET method 408 may result in a "budget 
remaining" field in a budget UDE being decremented by an 
amount specified by BILLING method 406. 

The information content may be released, or other action 
taken, once the various methods 402, 404, 406, 408 have 
processed the event. 

As mentioned above, PERCs 808 in the preferred 
embodiment may be provided with "control methods" that in 
efifect "oversee" performance of the other required methods in a 
control process. Figure 46 shows how the required 
methods/processes 402, 404, 406, and 408 of Figure 45 can be 
organized and controlled by a control method 410. Control 
method 410 may call, dispatch events, or otherwise invoke the 
other methods 402, 404, 406, 408 and otherwise supervise the 
processing performed in response to an "event." 
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Control methods operate at the level of control sets 906 
within PERCs 808. They provide structure, logic, and flow of 
control between disparate acquired methods 1000. This 
mechanism permits the content provider to create any desired 
chain of processing, and also allows the specific chain of 
processing to be modified (within permitted limits) by 
downstream redistributors. This control structure concept 
provides great flexibility. 

Figure 47 shows an example of an "aggregate" method 412 
which collects METER method 404, BUDGET method 406 and 
BILLING method 408 into an "aggregate* processing flow. 
Aggregate method 412 may, for example, combine various 
elements of metering, budgeting and billing into a single method 
1000. Aggregate method 412 may provide increased efficiency as 
a result of processing METER method 404, BUDGET method 406 
and BILLING method 408 aggregately, but may decrease 
flexibility because of decreased modularity. 

Many different methods can be in effect simultaneously. 
Figure 48 shows an example of preferred embodiment event 
processing using multiple METER methods 404 and multiple 
BUDGET methods 1408. Some events may be subject to many 
different required methods operating independently or 
cumulatively. For example, in the example shown in Figure 48, 
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meter method 404a may maintain meter trail and meter 
information records that are independent from the meter trail 
and meter information records maintained by METER method 
404b. Similarly, BUDGET method 408a may maintain records 
independently of those records maintained by BUDGET method 
408b. Some events may bypass BILLING method 408 while 
nevertheless being processed by meter method 404a and 
BUDGET method 408a. A variety of different variations are 
possible. 

REPRESENTATIVE EXAMPLES OF VDE METHODS 

Although methods 1000 can have virtually unlimited 
variety and some may even be user-defined, certain basic "use" 
type methods are preferably used in the preferred embodiment to 
control most of the more fundamental object manipulation and 
other functions provided by VDE 100. For example, the following 
high level methods would typically be provided for object 
manipulation: 

OPEN method 

READ method 

WRITE method 

CLOSE method. 

An OPEN method is used to control opening a container so 
its contents may be accessed. A READ method is used to control 
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the access to contents in a container. A WRITE method is used to 
control the insertion of contents into a container. A CLOSE 
method is used to close a container that has been opened. 

Subsidiary methods are provided to perform some of the 
steps required by the OPEN, READ, WRITE and/or CLOSE 
methods. Such subsidiary methods may include the following: 

ACCESS method 

PANIC method 

ERROR method 

DECRYPT method 

ENCRYPT method 

DESTROY content method 

INFORMATION method 

OBSCURE method 

FINGERPRINT method 

EVENT method. 

CONTENT method 

EXTRACT method 

EMBED method 

METER method 

BUDGET method 

REGISTER method 

• BILLING method 

• AUDIT method 
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An ACCESS method may be used to physically access 
content associated with an opened container (the content can be 
anywhere). A PANIC method may be used to disable at least a 
portion of the VDE node if a security violation is detected. An 
ERROR method may be used to handle error conditions. A 
DECRYPT method is used to decrypt encrypted information. An 
ENCRYPT method is used to encrypt information. A DESTROY 
content method is used to destroy the ability to access specific 
content within a container. An INFORMATION method is used 
to provide public information about the contents of a container. 
An OBSCURE method is used to devalue content read from an 
opened container (e.g., to write the word "SAMPLE" over a 
displayed image). A FINGERPRINT method is used to mark 
content to show who has released it from the secure container. 
An event method is used to convert events into different events 
for response by other methods. 

Open 

Figure 49 is a flowchart of an example of preferred 
embodiment process control steps for an example of an OPEN 
method 1500. Different OPEN methods provide different 
detailed steps. However, the OPEN method shown in Figure 49 
is a representative example of a relatively full-featured "open" 
method provided by the preferred embodiment. Figure 49 shows 
a macroscopic view of the OPEN method. Figures 49a-49f are 
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together an example of detailed program controlled steps 
performed to implement the method shown in Figure 49. 

The OPEN method process starts with an "open event." 
This open event may be generated by a user application, an 
operating system intercept or various other mechanisms for 
capturing or intercepting control. For example, a user 
application may issue a request for access to a particular content 
stored within the VDE container. As another example, another 
method may issue a command. 

In the example shown, the open event is processed by a 
control method 1502. Control method 1502 may call other 
methods to process the event. For example, control method 1502 
may call an EVENT method 1504, a METER method 1506, a 
BILLING method 1508, and a BUDGET method 1510. Not all 
OPEN control methods necessarily call of these additional 
methods, but the OPEN method 1500 shown in Figure 49 is a 
representative example. 

Control method 1502 passes a description of the open event 
to EVENT method 1504. EVENT method 1504 may determine, 
for example, whether the open event is permitted and whether 
the open event is significant in the sense that it needs to be 
processed by METER method 1506, BILLING method 1508, 
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and/or BUDGET method 1510. EVENT method 1504 may 
maintain audit trail information within an audit trail TIDE, and 
may determine permissions and significance of the event by 
using an Event Method Data Element (MDE). EVENT method 
1504 may also map the open event into an "atomic element" and 
count that may be processed by METER method 1506, BILLING 
method 1508, and/or BUDGET method 1510. 

In OPEN method 1500, once EVENT method 1504 has 
been called and returns successfully, control method 1502 then 
may call METER method 1506 and pass the METER method, the 
atomic element and count returned by EVENT method 1504. 
METER method 1506 may maintain audit trail information in a 
METER method Audit Trail UDE, and may also maintain meter 
information in a METER method UDE. In the preferred 
embodiment, METER method 1506 returns a meter value to 
control method 1502 assuming successful completion. 

In the preferred embodiment, control method 1502 upon 
receiving an indication that METER method 1506 has completed 
successfully, then calls BILLING method 1508. Control method 
1502 may pass to BILLING method 1508 the meter value 
provided by METER method 1506. BILLING method 1508 may 
read and update billing information maintained in a BILLING 
method map MDE, and may also maintain and update audit trail 
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in a BILLING method Audit Trail UDE. BILLING method 1508 
may return a billing amount and a completion code to control 
method 1502. 

Assuming BILLING method 1508 completes successfully, 
control method 1502 may pass the billing value provided by 
BILLING method 1508 to BUDGET method 1510. BUDGET 
method 1510 may read and update budget information within a 
BUDGET method UDE, and may also maintain audit trail 
information in a BUDGET method Audit Trail UDE. BUDGET 
method 1510 may return a budget value to control method 1502, 
and may also return a completion code indicating whether the 
open event exceeds the user's budget (for this type of event). 

Upon completion of BUDGET method 1510, control method 
1502 may create a channel and establish read/use control 
information in preparation for subsequent calls to the READ 
method. 

Figures 49a-49f are a more detailed description of the 
OPEN method 1500 example shown in Figure 49. Referring to 
Figure 49a, in response to an open event, control method 1502 
first may determine the identification of the object to be opened 
and the identification of the user that has requested the object to 
be opened (block 1520). Control method 1502 then determines 
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whether the object to be opened is registered for this user 
(decision block 1522). It makes this determination at least in 
part in the preferred embodiment by reading the PERC 808 and 
the User Rights Table (URT) element associated with the 
particular object and particular user determined by block 1520 
(block 1524). If the user is not registered for this particular 
object ("no" exit to decision block 1522), then control method 1502 
may call the REGISTER method for the object and restart the 
OPEN method 1500 once registration is complete (block 1526). 
The REGISTER method block 1526 may be an independent 
process and may be time independent. It may, for example, take 
a relatively long time to complete the REGISTER method (say if 
the VDE distributor or other participant responsible for 
providing registration wants to perform a credit check on the 
user before registering the user for this particular object). 

Assuming the proper URT for this user and object is 
present such that the object is registered for this user ("yes" exit 
to decision block 1522), control method 1502 may determine 
whether the object is already open for this user (decision block 
1528). This test may avoid creating a redundant channel for 
opening an object that is already open. Assuming the object is 
not already open ("no" exit to decision block 1528), control method 
1502 creates a channel and binds appropriate open control 
elements to it (block 1530). It reads the appropriate open control 
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elements from the secure database (or the container, such as, for 
example, in the case of a travelling object), and "binds" or links" 
these particular appropriate control elements together in order to 
control opening of the object for this user. Thus, block 1530 
associates an event with one or more appropriate method core(s), 
appropriate load modules, appropriate User Data Elements, and 
appropriate Method Data Elements read from the secure 
database (or the container) (block 1532). At this point, control 
method 1502 specifies the open event (which started the OPEN 
method to begin with), the object ID and user ID (determined by 
block 1520), and the channel ID of the channel created by block 
1530 to subsequent EVENT method 1504, METER method 1506, 
BILLING method 1508 and BUDGET method 1510 to provide a 
secure database "transaction" (block 1536). Before doing so, 
control method 1502 may prime an audit process (block 1533) 
and write audit information into an audit UDE (block 1534) so a 
record of the transaction exists even if the transaction fails or is 
interfered with. 

The detail steps performed by EVENT method 1504 are set 
forth on Figure 49b. EVENT method 1504 may first prime an 
event audit trail if required (block 1538) which may write to an 
EVENT Method Audit Trail UDE (block 1540). EVENT method 
1504 may then perform the step of mapping the open event to an 
atomic element number and event count using a map MDE (block 
1542). The EVENT method map MDE may be read from the 
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secure database (block 1544). This mapping process performed 
by block 1542 may, for example, determine whether or not the 
open event is meterable, billable, or budgetable, and may 
transform the open event into some discrete atomic element for 
metering, billing and/or budgeting. As one example, block 1542 
might perform a one-to-one mapping between open events and 
"open" atomic elements, or it may only provide an open atomic 
element for every fifth time that the object is opened. The map 
block 1542 preferably returns the open event, the event count, 
the atomic element number, the object ID, and the user ID. This 
information may be written to the EVENT method Audit Trail 
UDE (block 1546, 1548). In the preferred embodiment, a test 
(decision block 1550) is then performed to determine whether the 
EVENT method failed. Specifically, decision block 1550 may 
determine whether an atomic element number was generated. If 
no atomic element number was generated (e.g., meaning that the 
open event is not significant for processing by METER method 
1506, BILLING method 1508 and/or BUDGET method 1510), 
then EVENT method 1504 may return a "fail" completion code to 
control method 1502 ("no" exit to decision block 1550). 

Control method 1502 tests the completion code returned by 
EVENT method 1504 to determine whether it failed or was 
successful (decision block 1552). If the EVENT method failed 
Cno a exit to decision block 1552), control method 1502 may "roll 
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back" the secure database transaction (block 1554) and return 
itself with an indication that the OPEN method failed (block 
1556). In this context, "rolling back a the secure database 
transaction means, for example, "undoing" the changes made to 
audit trail UDE by blocks 1540, 1548. However, this "roll back" 
performed by block 1554 in the preferred embodiment does not 
"undo" the changes made to the control method audit UDE by 
blocks 1532, 1534. 

Assuming the EVENT method 1504 completed 
successfully, control method 1502 then calls the METER method 
1506 shown on Figure 49c. In the preferred embodiment, 
METER method 1506 primes the meter audit trail if required 
(block 1558), which typically involves writing to a METER 
method audit trail UDE (block 1560). METER method 1506 may 
then read a METER method UDE from the secure database 
(block 1562), modify the meter UDE by adding an appropriate 
event count to the meter value contained in the meter UDE 
(block 1564), and then writing the modified meter UDE back to 
the secure database (block 1562). In other words, block 1564 may 
read the meter UDE, increment the meter count it contains, and 
write the changed meter UDE back to the secure database. In 
the preferred embodiment, METER method 1506 may then write 
meter audit trail information to the METER method audit trail 
UDE if required (blocks 1566, 1568). METER method 1506 
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preferably next performs a test to determine whether the meter 
increment succeeded (decision block 1570). METER method 1506 
returns to control method 1502 with a completion code (e.g., 
succeed or fail) and a meter value determined by block 1564. 

Control method 1502 tests whether the METER method 
succeeded by examining the completion code, for example 
(decision block 1572). If the METER method failed (W exit to 
decision block 1572), then control method 1502 "rolls back" a 
secure database transaction (block 1574), and returns with an 
indication that the OPEN method failed (block 1576). Assuming 
the METER method succeeded ("yes" exit to decision block 1572), 
control method 1502 calls the BILLING method 1508 and passes 
it the meter value provided by METER method 1506. 

An example of steps performed by BILLING method 1508 
is set forth in Figure 49d. BILLING method 1508 may prime a 
billing audit trail if required (block 1578) by writing to a 
BILLING method Audit Trail TIDE within the secure database 
(block 1580). BILLING method 1508 may then map the atomic 
element number, count and meter value to a billing amount using 
a BILLING method map MDE read from the secure database 
(blocks 1582, 1584). Providing an independent BILLING method 
map MDE containing, for example, price list information, allows 
separately deliverable pricing for the billing process. The 
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resulting billing amount generated by block 1582 may be written 
to the BILLING method Audit Trail UDE (blocks 1586, 1588), 
and may also be returned to control method 1502. In addition, 
BILLING method 1508 may determine whether a billing amount 
was properly selected by block 1582 (decision block 1590). In this 
example, the test performed by block 1590 generally requires 
more than mere examination of the returned billing amount, 
since the b illing amount may be changed in unpredictable ways 
as specified by BILLING method map MDE. Control then 
returns to control method 1502, which tests the completion code 
provided by BILLING method 1508 to determine whether the 
BILLING method succeeded or failed (block 1592). If the 
BILLING method failed ("no" exit to decision block 1592), control 
method 1502 may "roll back" the secure database transaction 
(block 1594), and return an indication that the OPEN method 
failed (block 1596). Assuming the test performed by decision 
block 1592 indicates that the BILLING method succeeded ("yes" 
exit to decision block 1592), then control method 1502 may call 
BUDGET method 1510. 

Other BILLING methods may use site, user and/or usage 
information to establish, for example, pricing information. For 
example, information concerning the presence or absence of an 
object may be used in establishing "suite" purchases, competitive 
discounts, etc. Usage levels may be factored into a BILLING 
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method to establish price breaks for different levels of usage. A 
currency translation feature of a BILLING method may allow 
purchases and/or pricing in many different currencies. Many 
other possibilities exist for determining an amount of budget 
consumed by an event that may be incorporated into BILLING 
methods. 

An example of detailed control steps performed by 
BUDGET method 1510 is set forth in Figure 49e. BUDGET 
method 1510 may prime a budget audit trail if required by 
writing to a budget trail UDE (blocks 1598, 1600). BUDGET 
method 1510 may next perform a billing operation by adding a 
billing amount to a budget value (block 1602). This operation 
may be performed, for example, by reading a BUDGET method 
UDE from the secure database, modifying it, and writing it back 
to the secure database (block 1604). BUDGET method 1510 may 
then write the budget audit trail information to the BUDGET 
method Audit Trail UDE (blocks 1606, 1608). BUDGET method 
1510 may finally, in this example, determine whether the user 
has nm out of budget by determining whether the budget value 
calculated by block 1602 is out of range (decision block 1610). If 
the user has run out of budget ("yes" exit to decision block 1610), 
the BUDGET method 1510 may return a "fail completion" code to 
control method 1502. BUDGET method 1510 then returns to 
control method 1502, which tests whether the BUDGET method 

554 



WO 96/27155 



PCT/US96/02303 



completion code was successful (decision block 1612). If the 
BUDGET method failed ("no" exit to decision block 1612), control 
method 1502 may "roll back" the secure database transaction and 
itself return with an indication that the OPEN method failed 
(blocks 1614, 1616). Assuming control method 1502 determines 
that the BUDGET method was successful, the control method 
may perform the additional steps shown on Figure 49f. For 
example, control method 1502 may write an open audit trail if 
required by writing audit information to the audit UDE that was 
primed at block 1532 (blocks 1618, 1620). Control method 1502 
may then establish a read event processing (block 1622), using 
the User Right Table and the PERC associated with the object 
and user to establish the channel (block 1624). This channel may 
optionally be shared between users of the VDE node 600, or may 
be used only by a specified user. 

Control method 1502 then, in the preferred embodiment, 
tests whether the read channel was established successfully 
(decision block 1626). If the read channel was not successfully 
established ("no" exit to decision block 1626), control method 
1502 "rolls back" the secured database transaction and provides 
an indication that the OPEN method failed (blocks 1628, 1630). 
Assuming the read channel was successfully established ("yes" 
exit to decision block 1626), control method 1502 may "commit" 
the secure database transaction (block 1632). This step of 
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"committing" the secure database transaction in the preferred 
embodiment involves, for example, deleting intermediate values 
associated with the secure transaction that has just been 
performed and, in one example, writing changed UDEs and 
MDEs to the secure database. It is generally not possible to "roll 
back" a secure transaction once it has been committed by block 
1632. Then, control method 1502 may "tear down" the channel 
for open processing (block 1634) before terminating (block 1636). 
In some arrangements, such as multi-tasking VDE node 
environments, the open channel may be constantly maintained 
and available for use by any OPEN method that starts. In other 
implementations, the channel for open processing may be rebuilt 
and restarted each time an OPEN method starts. 

Read 

Figure 50, 50a-50f show examples of process control steps 
for performing a representative example of a READ method 1650. 
Comparing Figure 50 with Figure 49 reveals that the same 
overall high level processing may typically be performed for 
READ method 1650 as was described in connection with OPEN 
method 1500. Thus, READ method 1650 may call a control 
method 1652 in response to a read event, the control method in 
turn invoking an EVENT method 1654, a METER method 1656, 
a BILLING method 1658 and a BUDGET method 1660. In the 
preferred embodiment, READ control method 1652 may request 
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methods to fingerprint and/or obscure content before releasing 
the decrypted content. 

Figures 50a-50e are similar to Figures 49a-49e. Of course, 
even though the same user data elements may be used for both 
the OPEN method 1500 and the READ method 1650, the method 
data elements for the READ method may be completely different, 
and in addition, the user data elements may provide different 
auditing, metering, billing and/or budgeting criteria for read as 
opposed to open processing. 

Referring to Figure 50f, the READ control method 1652 
must determine which key to use to decrypt content if it is going 
to release decrypted content to the user (block 1758). READ 
control method 1652 may make this key determination based, in 
part, upon the PERC 808 for the object (block 1760). READ 
control method 1652 may then call an ACCESS method to 
actually obtain the encrypted content to be decrypted (block 
1762). The content is then decrypted using the key determined 
by block 1758 (block 1764). READ control method 1652 may then 
determine whether a "fingerprint" is desired (decision block 
1766). If fingerprinting of the content is desired Cyes" exit of 
decision block 1766), READ control method 1652 may call the 
FINGERPRINT method (block 1768). Otherwise, READ control 
method 1652 may determine whether it is desired to obscure the 
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decrypted content (decision block 1770). If so, BEAD control 
method 1652 may call an OBSCURE method to perform this 
function (block 1772). Finally, READ control method 1652 may 
commit the secure database transaction (block 1774), optionally 
tear down the read channel (not shown), and terminate (block 
1776). 



Write 

Figures 51, 51a-51f are flowcharts of examples of process 
control steps used to perform a representative example of a 
WRITE method 1780 in the preferred embodiment. WRITE 
method 1780 uses a control method 1782 to call an EVENT 
method 1784, METER method 1786, BILLING method 1788, and 
BUDGET method 1790 in this example. Thus, writing 
information into a container (either by overwriting information 
already stored in the container or adding new information to the 
container) in the preferred embodiment may be metered, billed 
and/or budgeted in a manner similar to the way opening a 
container and reading from a container can be metered, billed 
and budgeted. As shown in Figure 51, the end result of WRITE 
method 1780 is typically to encrypt content, update the container 
table of contents and related information to reflect the new 
content, and write the content to the object. 
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Figure 51a for the WRITE control method 1782 is similar 
to Figure 49a and Figure 50a for the OPEN control method and 
the READ control method, respectively. However, Figure 51b is 
slightly different from its open and read counterparts. In 
particular, block 1820 is performed if the WRITE EVENT method 
1784 fails. This block 1820 updates the EVENT method map 
MDE to reflect new data. This is necessary to allow information 
written by block 1810 to be read by Figure 51b READ method 
block 1678 based on the same (but now updated) EVENT method 
map MDE. 

Looking at Figure 51f, once the EVENT, METER, 
BILLING and BUDGET methods have returned successfully to 
WRITE control method 1782, the WRITE control method writes 
audit information to Audit UDE (blocks 1890, 1892), and then 
determines (based on the PERC for the object and user and an 
optional algorithm) which key should be used to encrypt the 
content before it is written to the container (blocks 1894, 1896). 
CONTROL method 1782 then encrypts the content (block 1898) 
possibly by calling an ENCRYPT method, and writes the 
encrypted content to the object (block 1900). CONTROL method 
1782 may then update the table of contents (and related 
information) for the container to reflect the newly written 
information (block 1902), commit the secure database transaction 
(block 1904), and return (block 1906). 
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Close 

Figure 52 is a flowchart of an example of process control 
steps to perform a representative example of a CLOSE method 
1920 in the preferred embodiment. CLOSE method 1920 is used 
to close an open object. In the preferred embodiment, CLOSE 
method 1920 primes an audit trail and writes audit information 
to an Audit UDE (blocks 1922, 1924). CLOSE method 1920 then 
may destroy the current channel(s) being used to support and/or 
process one or more open objects (block 1926). As discussed 
above, in some (e.g., multi-user or multi-tasking) installations, 
the step of destroying a channel is not needed because the 
channel may be left operating for processing additional objects for 
the same or different users. CLOSE method 1920 also releases 
appropriate records and resources associated with the object at 
this time (block 1926). The CLOSE method 1920 may then write 
an audit trail (if required) into an Audit UDE (blocks 1928, 1930) 
before completing. 

Event 

Figure 53a is a flowchart of example process control steps 
provided by a more general example of an EVENT method 1940 
provided by the preferred embodiment. Examples of EVENT 
methods are set forth in Figures 49b, 50b and 51b and are 
described above. EVENT method 1940 shown in Figure 53a is 
somewhat more generalized than the examples above. Like the 
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EVENT method examples above, EVENT method 1940 receives 
an identification of the event along with an event cotmt and event 
parameters. EVENT method 1940 may first prime an EVENT 
audit trail (if required) by writing appropriate information to an 
EVENT method Audit Trail UDE (blocks 1942, 1944). EVENT 
method 1940 may then obtain and load an EVENT method map 
DTD from the secure database (blocks 1946, 1948). This EVENT 
method map DTD describes, in this example, the format of the 
EVENT method map MDE to be read and accessed immediately 
subsequently (by blocks 1950, 1952). In the preferred 
embodiment, MDEs and UDEs may have any of various different 
formats, and their formats may be flexibly specified or changed 
dynamically depending upon the installation, user, etc. The 
DTD, in effect, describes to the EVENT method 1940 how to read 
from the EVENT method map MDE. DTDs are also used to 
specify how methods should write to MDEs and UDEs, and thus 
may be used to implement privacy filters by, for example, 
preventing certain confidential user information from being 
written to data structures that will be reported to third parties. 

Block 1950 Cmap event to atomic element # and event 
count using a Map MDE") is in some sense the "heart" of EVENT 
method 1940. This step "maps" the event into an "atomic 
element number" to be responded to by subsequently called 
methods. An example of process control steps performed by a 
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somewhat representative example of this "mapping" step 1950 is 
shown in Figure 53b. 

The Figure 53b example shows the process of converting a 
READ event that is associated with requesting byte range 1001- 
1500 from a specific piece of content into an appropriate atomic 
element. The example EVENT method mapping process (block 
1950 in Figure 53a) can be detailed as the representative process 
shown in Figure 53b. 

EVENT method mapping process 1950 may first look up 
the event code (READ) in the EVENT method MDE (1952) using 
the EVENT method map DTD (1948) to determine the structure 
and contents of the MDE. A test might then be performed to 
determine if the event code was found in the MDE (1956), and if 
not ("No" branch), the EVENT method mapping process may the 
terminate (1958) without mapping the event to an atomic 
element number and count. If the event was found in the MDE 
(Tes w branch), the EVENT method mapping process may then 
compare the event range (e.g., bytes 1001-1500) against the 
atomic element to event range mapping table stored in the MDE 
(block 1960). The comparison might yield one or more atomic 
element numbers or the event range might not be found in the 
mapping table. The result of the comparison might then be 
tested (block 1962) to determine if any atomic element numbers 
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were found in the table. If not (W branch), the EVENT method 
mapping process may terminate without selecting any atomic 
element numbers or counts (1964). If the atomic element 
numbers were found, the process might then calculate the atomic 
element count from the event range (1966). In this example, the 
process might calculate the number of bytes requested by 
subtracting the upper byte range from the lower byte range (e.g., 
1500 - 1001 + 1 = 500). The example EVENT method mapping 
process might then terminate (block 1968) and return the atomic 
element number(s) and counts. 

EVENT method 1940 may then write an EVENT audit 
trail if required to an EVENT method Audit Trail UDE (block 
1970, 1972). EVENT method 1940 may then prepare to pass the 
atomic element number and event count to the calling CONTROL 
method (or other control process) (at exit point 1978). Before 
that, however, EVENT method 1940 may test whether an atomic 
element was selected (decision block 1974). If no atomic element 
was selected, then the EVENT method may be failed (block 
1974). This may occur for a number of reasons. For example, the 
EVENT method may fail to map an event into an atomic element 
if the user is not authorized to access the specific areas of content 
that the EVENT method MDE does not describe. This 
mechanism could be used, for example, to distribute customized 
versions of a piece of content and control access to the various 
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versions in the content object by altering the EVENT method 
MDE delivered to the user. A specific use of this technology 
mi ght be to control the distribution of different language (e.g., 
English, French, Spanish) versions of a piece of content. 

Billing 

Figure 53c is a flowchart of an example of process control 
steps performed by a BILLING method 1980. Examples of 
BILLING methods are set forth in Figures 49d, 50d, and 51d and 
are described above. BILLING method 1980 shown in Figure 53c 
is somewhat more generalized than the examples above. Like the 
BILLING method examples above, BILLING method 1980 
receives a meter value to determine the amount to bill. BILLING 
method 1980 may first prime a BILLING audit trail (if required) 
by writing appropriate information to the BILLING method 
Audit Trail UDE (blocks 1982, 1984). BILLING method 1980 
may then obtain and load a BILLING method map DTD from the 
secure database (blocks 1985, 1986), which describes the 
BILLING method map MDE (e.g., a price list, table, or 
parameters to the b illing amount calculation algorithm) that 
should be used by this BILLING method. The BILLING method 
map MDE may be delivered either as part of the content object or 
as a separately deliverable component that is combined with the 
control information at registration. 
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The BILLING method map MDE in this example may 
describe the pricing algorithm that should be used in this 
BILLING method (e.g., bill $0,001 per byte of content released). 
Block 1988 ("Map meter value to billing amount") functions in 
the same manner as block 1950 of the EVENT method; it maps 
the meter value to a billing value. Process step 1988 may also 
interrogate the secure database (as limited by the privacy filter) 
to deter min e if other objects or information (e.g., user 
information) are present as part of the BILLING method 
algorithm. 

BILLING method 1980 may then write a BILLING audit 
trail if required to a BILLING method Audit Trail UDE (block 
1990, 1992), and may prepare to return the billing amount to the 
calling CONTROL method (or other control process). Before that, 
however, BILLING method 1980 may test whether a billing 
amount was determined (decision block 1994). If no billing 
amount was determined, then the BILLING method may be 
failed (block 1996). This may occur if the user is not authorized 
to access the specific areas of the pricing table that the BILLING 
method MDE describes (e.g., you may purchase not more than 
$100.00 of information from this content object). 
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Access 

Figure 54 is a flowchart of an example of program control 
steps performed by an ACCESS method 2000. As described 
above, an ACCESS method may be used to access content 
embedded in an object 300 so it can be written to, read from, or 
otherwise manipulated or processed. In many cases, the 
ACCESS method may be relatively trivial since the object may, 
for example, be stored in a local storage that is easily accessible. 
However, in the general case, an ACCESS method 2000 must go 
through a more complicated procedure in order to obtain the 
object. For example, some objects (or parts of objects) may only 
be available at remote sites or may be provided in the form of a 
real-time download or feed (e.g., in the case of broadcast 
transmissions). Even if the object is stored locally to the VDE 
node, it may be stored as a secure or protected object so that it is 
not directly accessible to a calling process. ACCESS method 2000 
establishes the connections, routings, and security requisites 
needed to access the object. These steps may be performed 
transparently to the calling process so that the calling process 
only needs to issue an access request and the particular ACCESS 
method corresponding to the object or class of objects handles all 
of the details and logistics involved in actually accessing the 
object. 
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ACCESS method 2000 may first prime an ACCESS audit 
trail (if required) by writing to an ACCESS Audit Trail UDE 
(blocks 2002, 2004). ACCESS method 2000 may then read and 
load an ACCESS method DTD in order to determine the format 
of an ACCESS MDE (blocks 2006, 2008). The ACCESS method 
MDE specifies the source and routing information for the 
particular object to be accessed in the preferred embodiment. 
Using the ACCESS method DTD, ACCESS method 2000 may 
load the correction parameters (e.g., by telephone number, 
account ID, password and/or a request script in the remote 
resource dependent language). 

ACCESS method 2000 reads the ACCESS method MDE 
from the secure database, reads it in accordance with the 
ACCESS method DTD, and loads encrypted content source and 
routing information based on the MDE (blocks 2010, 2012). This 
source and routing information specifies the location of the 
encrypted content. ACCESS method 2000 then determines 
whether a connection to the content is available (decision block 
2014). This "connection" could be, for example, an on-line 
connection to a remote site, a real-time information feed, or a 
path to a secure/protected resource, for example. If the 
connection to the content is not currently available ("No" exit of 
decision block 2014), then ACCESS method 2000 takes steps to 
open the connection (block 2016). ff the connection fails (e.g., 
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because the user is not authorized to access a protected secure 
resource), then the ACCESS method 2000 returns with a failure 
indication (termination point 2018). If the open connection 
succeeds, on the other hand, then ACCESS method 2000 obtains 
the encrypted content (block 2020). ACCESS method 2000 then 
writes an ACCESS audit trail if required to the secure database 
ACCESS method Audit Trail UDE (blocks 2022, 2024), and then 
terminates (terminate point 2026). 

Decrypt and Encrypt 

Figure 55a is a flowchart of an example of process control 
steps performed by a representative example of a DECRYPT 
method 2030 provided by the preferred embodiment. DECRYPT 
method 2030 in the preferred embodiment obtains or derives a 
decryption key from an appropriate PERC 808, and uses it to 
decrypt a block of encrypted content. DECRYPT method 2030 is 
passed a block of encrypted content or a pointer to where the 
encrypted block is stored. DECRYPT 2030 selects a key number 
from a key block (block 2032). For security purposes, a content 
object may be encrypted with more than one key. For example, a 
movie may have the first 10 minutes encrypted using a first key, 
the second 10 minutes encrypted with a second key, and so on. 
These keys are stored in a PERC 808 in a structure called a "key 
block." The selection process involves determining the correct key 
to use from the key block in order to decrypt the content. The 
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process for this selection is similar to the process used by EVENT 
methods to map events into atomic element numbers. DECRYPT 
method 2030 may then access an appropriate PERC 808 from the 
secure database 610 and loads a key (or "seed") from a PERC 
(blocks 2034, 2036). This key information may be the actual 
decryption key to be used to decrypt the content, or it may be 
information from which the decryption key may be at least in 
part derived or calculated. If necessary, DECRYPT method 2030 
computes the decryption key based on the information read from 
PERC 808 at block 2034 (block 2038). DECRYPT method 2030 
then uses the obtained and/or calculated decryption key to 
actually decrypt the block of encrypted information (block 2040). 
DECRYPT method 2030 outputs the decrypted block (or the 
pointer indicating where it may be found), and terminates 
(termination point 2042). 

Figure 55b is a flowchart of an example of process control 
steps performed by a representative example of an ENCRYPT 
method 2050. ENCRYPT method 2050 is passed as an input, a 
block of information to encrypt (or a pointer indicating where it 
may be found). ENCRYPT method 2050 then may determine an 
encryption key to use from a key block (block 2052). The 
encryption key selection makes a determination if a key for a 
specific block of content to be written already exists in a key block 
stored in PERC 808. If the key already exists in the key block, 
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then the appropriate key number is selected. If no such key 
exists in the key block, a new key is calculated using an 
algorithm appropriate to the encryption algorithm. This key is 
then stored in the key block of PERC 808 so that DECRYPT 
method 2030 may access the key in order to decrypt the content 
stored in the content object. ENCRYPT method 2050 then 
accesses the appropriate PERC to obtain, derive and/or compute 
an encryption key to be used to encrypt the information block 
(blocks 2054, 2056, 2058, which are similar to Figure 55a blocks 
2034, 2036, 2038). ENCRYPT method 2050 then actually 
encrypts the information block using the obtained and/or derived 
encryption key (block 2060) and outputs the encrypted 
information block or a pointer where it can be found before 
terminating (termination point 2062). 
Content 

Figure 56 is a flowchart of an example of process control 
steps performed by a representative of a CONTENT method 2070 
provided by the preferred embodiment. CONTENT method 2070 
in the preferred embodiment builds a "synopsis" of protected 
content using a secure process. For example, CONTENT method 
2070 may be used to derive unsecure ("public") information from 
secure content. Such derived public information might include, 
for example, an abstract, an index, a table of contents, a directory 
of files, a schedule when content may be available, or excerpts 
such as for example, a movie "trailer." 
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CONTENT method 2070 begins by determining whether 
the derived content to be provided must be derived from secure 
contents, or whether it is already available in the object in the 
form of static values (decision block 2070). Some objects may, for 
example, contain prestored abstracts, indexes, tables of contents, 
etc., provided expressly for the purpose of being extracted by the 
CONTENT method 2070. If the object contains such static values 
("static" exit to decision block 2072), then CONTENT method 
2070 may simply read this static value content information from 
the object (block 2074), optionally decrypt, and release this 
content description (block 2076). If, on the other hand, 
CONTENT method 2070 must derive the synopsis/content 
description from the secure object ("derived" exit to decision block 
2072), then the CONTENT method may then securely read 
information from the container according to a synopsis algorithm 
to produce the synopsis (block 2078). 

Extract and Embed 

Figure 57a is a flowchart of an example of process control 
steps performed by a representative example of an EXTRACT 
method 2080 provided by the preferred embodiment. EXTRACT 
method 2080 is used to copy or remove content from an object and 
place it into a new object. In the preferred embodiment, the 
EXTRACT method 2080 does not involve any release of content, 
but rather simply takes content from one container and places it 



571 



WO 96/27155 



PCT/DS96/02303 



into another container, both of which may be secure. Extraction 
of content differs from release in that the content is never 
exposed outside a secure container. Extraction and Embedding 
are complementary functions; extract takes content from a 
container and creates a new container containing the extracted 
content and any specified control information associated with 
that content. Embedding takes content that is already in a 
container and stores it (or the complete object) in another 
container directly and/or by reference, integrating the control 
information associated with existing content with those of the 
new content. 

EXTRACT method 2080 begins by priming an Audit UDE 
(blocks 2082, 2084). EXTRACT method then calls a BUDGET 
method to make sure that the user has enough budget for (and is 
authorized to) extract content from the original object (block 
2086). If the user's budget does not permit the extraction ("no* 
exit to decision block 2088), then EXTRACT method 2080 may 
write a failure audit record (block 2090), and terminate 
(termination point 2092). If the user's budget permits the 
extraction ("yes" exit to decision block 2088), then the EXTRACT 
method 2080 creates a copy of the extracted object with specified 
rules and control information (block 2094). In the preferred 
embodiment, this step involves calling a method that actually 
controls the copy. This step may or may not involve decryption 
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and encryption, depending on the particular the PERC 808 
associated with the original object, for example. EXTRACT 
method 2080 then checks whether any control changes are 
permitted by the rights authorizing the extract to begin with 
(decision block 2096). In some cases, the extract rights require 
an exact copy of the PERC 808 associated with the original object 
(or a PERC included for this purpose) to be placed in the new 
(destination) container ("no" exit to decision block 2096). If no 
control changes are permitted, then extract method 2080 may 
simply write audit information to the Audit UDE (blocks 2098, 
2100) before terminating (terminate point 2102). If, on the other 
hand, the extract rights permit the user to make control changes 
("yes" to decision block 2096), then EXTRACT method 2080 may 
call a method or load module that solicits new or changed control 
information (e.g., from the user, the distributor who 
created/granted extract rights, or from some other source) from 
the user (blocks 2104, 2106). EXTRACT method 2080 may then 
call a method or load module to create a new PERC that reflects 
these user-specified control information (block 2104). This new 
PERC is then placed in the new (destination) object, the auditing 
steps are performed, and the process terminates. 

Figure 57b is an example of process control steps 
performed by a representative example of an EMBED method 
2110 provided by the preferred embodiment. EMBED method 
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2110 is similar to EXTRACT method 2080 shown in Figure 57 a. 
However, the EMBED method 2110 performs a slightly different 
function— it writes an object (or reference) into a destination 
container. Blocks 2112-2122 shown in Figure 57b are similar to 
blocks 2082-2092 shown in Figure 57a. At block 2124, EMBED 
method 2110 writes the source object into the destination 
container, and may at the same time extract or change the 
control information of the destination container. One alternative 
is to simply leave the control information of the destination 
container alone, and include the full set of control information 
associated with the object being embedded in addition to the 
original container control information. As an optimization, 
however, the preferred embodiment provides a technique 
whereby the control information associated with the object being 
embedded are "abstracted" and incorporated into the control 
information of the destination container. Block 2124 may call a 
method to abstract or change this control information. EMBED 
method 2110 then performs steps 2126-2130 which are similar to 
steps 2096, 2104, 2106 shown in Figure 57a to allow the user, if 
authorized, to change and/or specify control information 
associated with the embedded object and/or destination 
container. EMBED method 2110 then writes audit information 
into an Audit UDE (blocks 2132, 2134), before terminating (at 
termination point 2136). 
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ObBCure 

Figure 58a is a flowchart of an example of process control 
steps performed by a representative example of an OBSCURE 
method 2140 provided by the preferred embodiment. OBSCURE 
method 2140 is typically used to release secure content in 
devalued form. For example, OBSCURE method 2140 may 
release a high resolution image in a lower resolution so that a 
viewer can appreciate the image but not enjoy its full value. As 
another example, the OBSCURE method 2140 may place an 
obscuring legend (e.g., "COPY," "PROOF," etc.) across an image 
to devalue it. OBSCURE method 2140 may "obscure" text, 
images, audio information, or any other type of content. 

OBSCURE method 2140 first calls an EVENT method to 
determine if the content is appropriate and in the range to be 
obscured (block 2142). If the content is not appropriate for 
obscuring, the OBSCURE method terminates (decision block 
2144 "no" exit, terminate point 2146). Assuming that the content 
is to be obscured ("yes" exit to decision block 2144), then 
OBSCURE method 2140 determines whether it has previously 
been called to obscure this content (decision block 2148). 
Assuming the OBSCURE 2140 has not previously called for this 
object/content ("yes" exit to decision block 2148), the OBSCURE 
method 2140 reads an appropriate OBSCURE method MDE from 
the secure database and loads an obscure formula and/or pattern 
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from the MDE (blocks 2150, 2152). The OBSCURE method 2140 
may then apply the appropriate obscure transform based on the 
patters and/or formulas loaded by block 2150 (block 2154). The 
OBSCURE method then may terminate (terminate block 2156). 

Fingerprint 

Figure 58b is a flowchart of an example of process control 
steps performed by a representative example of a 
FINGERPRINT method 2160 provided by the preferred 
embodiment. FINGERPRINT method 2160 in the preferred 
embodiment operates to "mark" released content with a 
"fingerprint" identification of who released the content and/or 
check for such marks. This allows one to later determine who 
released unsecured content by examining the content. 
FINGERPRINT method 2160 may, for example, insert a user ID 
within a datastream representing audio, video, or binary format 
information. FINGERPRINT method 2160 is quite similar to 
OBSCURE method 2140 shown in Figure 58a except that the 
transform applied by FINGERPRINT method block 2174 
"fingerprints" the released content rather than obscuring it. 

Figure 58c shows an example of a "fingerprinting" 
procedure 2160 that inserts into released content "fingerprints" 
2161 that identify the object and/or property and/or the user that 
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requested the released content and/or the date and time of the 
release and/or other identification criteria of the released content. 

Such fingerprints 2161 can be "buried" - that is inserted in 
a manner that hides the fingerprints from typical users, 
sophisticated "hackers," and/or from all users, depending on the 
file format, the sophistication and/or variety of the insertion 
algorithms, and on the availability of original, non-fingeiprinted 
content (for comparison for reverse engineering of algorithm(s)). 
Inserted or embedded fingerprints 2161, in a preferred 
embodiment, may be at least in part encrypted to make them 
more secure. ^Such encrypted fingerprints 2161 may be 
embedded within released content provided in "clear" (plaintext) 
form. 

Fingerprints 2161 can be used for a variety of purposes 
including, for example, the often related purposes of proving 
misuse of released materials and proving the source of released 
content. Software piracy is a particularly good example where 
fingerprinting can be very useful. Fingerprinting can also help to 
enforce content providers' rights for most types of electronically 
delivered information including movies, audio recordings, 
multimedia, information databases, and traditional "literary" 
materials. Fingerprinting is a desirable alternative or addition to 
copy protection. 
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Most piracy of software applications, for example, occurs 
not with the making of an illicit copy by an individual for use on 
another of the individual's own computers, but rather in giving a 
copy to another party. This often starts a chain (or more 
accurately a pyramid) of illegal copies, as copies are handed from 
individual to individual. The fear of identification resulting from 
the embedding of a fingerprint 2161 will likely dissuade most 
individuals from participating, as many currently do, in 
widespread, "casual" piracy. In some cases, content may be 
checked for the presence of a fingerprint by a fingerprint method 
to help enforce content providers' rights. 

Different fingerprints 2161 can have different levels of 
security (e.g., one fingerprint 2161(1) could be 
readable/identifiable by commercial concerns, while another 
fingerprint 2161(2) could be readable only by a more trusted 
agency. The methods for generating the more secure fingerprint 
2161 might employ more complex encryption techniques (e.g., 
digital signatures) and/or obscuring of location methodologies. 
Two or more fingerprints 2161 can be embedded in different 
locations and/or using different techniques to help protect 
fingerprinted information against hackers. The more secure 
fingerprints might only be employed periodically rather than 
each time content release occurs, if the technique used to provide 
a more secure fingerprint involves an undesired amount of 
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additional overhead. This may nevertheless be effective since a 
principal objective of fingerprinting is deterrence — that is the 
fear on the part of the creator of an illicit copy that the copying 
will be found out. 

For example, one might embed a copy of a fingerprint 2161 
which might be readily identified by an authorized party— for 
example a distributor, service personal, client administrator, or 
clearinghouse using a VDE electronic appliance 600. One might 
embed one or more additional copies or variants of a fingerprint 
2161 (e.g., fingerprints carrying information describing some or 
all relevant identifying information) and this additional one or 
more fingerprints 2161 might be maintained in a more secure 
manner. 

Fingerprinting can also protect privacy concerns. For 
example, the algorithm and/or mechanisms needed to identify the 
fingerprint 2161 might be available only through a particularly 
trusted agent. 

Fingerprinting 2161 can take many forms. For example, in 
an image, the color of every N pixels (spread across an image, or 
spread across a subset of the image) might be subtly shifted in a 
visually unnoticeable manner (at least according to the normal, 
unaided observer). These shifts could be interpreted by analysis 
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of the image (with or without access to the original image), with 
each occurrence or lack of occurrence of a shift in color (or 
grayscale) being one or more binary "on or off* bits for digital 
information storage. The N pixels might be either consistent, or 
alternatively, pseudo-random in order (but interpretable, at least 
in part, by a object creator, object provider, chent'administrator, 
and/or VDE administrator). 

Other modifications of an image (or moving image, audio, 
etc.) which provide a similar benefit (that is, storing information 
in a form that is not normally noticeable as a result of a certain 
modification of the source information) may be appropriate, 
depending on the application. For example, certain subtle 
modifications in the frequency of stored audio information can be 
modified so as to be normally unnoticeable to the listener while 
still being readable with the proper tools. Certain properties of 
the storage of information might be modified to provide such 
slight but interpretable variations in polarity of certain 
information which is optically stored to achieve similar results. 
Other variations employing other electronic, magnetic, and/or 
optical characteristic may be employed. 

Content stored in files that employ graphical formats, such 
as Microsoft Windows word processing files, provide significant 
opportunities for Tburying" a fingerprint 2161. Content that 
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includes images and/or audio provides the opportunity to embed 
fingerprints 2161 that may be difficult for unauthorized 
individuals to identify since, in the absence of an 
"unfingerprinted" original for purposes of comparison, minor 
subtle variations at one or more time instances in audio 
frequencies, or in one or more video images, or the like, will be in 
themselves undiscernible given the normally unknown nature of 
the original and the large amounts of data employed in both 
image and sound data (and which is not particularly sensitive to 
minor variations). With formatted text documents, particularly 
those created with graphical word processors (such as Microsoft 
Windows or Apple Macintosh word processors and their DOS and 
Unix equivalents), fingerprints 2161 can normally be inserted 
unobtrusively into portions of the document data representation 
that are not normally visible to the end user (such as in a header 
or other non-displayed data field). 

Yet another form of fingerprinting, which may be 
particularly suitable for certain textual documents, would employ 
and control the formation of characters for a given font. 
Individual characters may have a slightly different visual 
formation which connotes certain ''fingerprint" information. This 
alteration of a given character's form would be generally 
undiscernible, in part because so many slight variations exist in 
versions of the same font available from different suppliers, and 
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in part because of the smallness of the variation. For example, in 
a preferred embodiment, a program such as Adobe Type Align 
could be used which, in its off-the-shelf versions, supports the 
ability of a user to modify font characters in a variety of ways. 
The mathematical definition of the font character is modified 
according to the user's instructions to produce a specific set of 
modifications to be applied to a character or font. Information 
content could be used in an analogous manner (as an alternative 
to user selections) to modify certain or all characters too subtly 
for user recognition under normal circumstances but which 
nevertheless provide appropriate encoding for the fingerprint 
2161. Various subtly different versions of a given character 
might be used within a single document so as to increase the 
ability to carry transaction related font fingerprinted 
information. 

Some other examples of applications for fingerprinting 
might include: 

1. In software programs, selecting certain 
interchangeable code fragments in such a way as to 
produce more or less identical operation, but on 
analysis, differences that detail fingerprint 
information. 

2. With databases, selecting to format certain fields, 
such as dates, to appear in different ways. 
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3. In games, adjusting backgrounds, or changing order 
of certain events, including noticeable or very subtle 
changes in timing and/or ordering of appearance of 
game elements, or slight changes in the look of 
elements of the game. 

Fingerprinting method 2160 is typically performed (if at 
all) at the point at which content is released from a content object 
300. However, it could also be performed upon distribution of an 
object to "mark" the content while still in encrypted form. For 
example, a network-based object repository could embed 
fingerprints 2161 into the content of an object before 
transmitting the object to the requester, the fingerprint 
information could identify a content requester/end user. This 
could help detect "spoof" electronic appliances 600 used to release 
content without authorization. 

Destroy 

Figure 59 is a flowchart of an example of process control 
steps performed by a representative performed by a DESTROY 
method 2180 provided by the preferred embodiment. DESTROY 
method 2180 removes the ability of a user to use an object by 
destroying the URT the user requires to access the object. In the 
preferred embodiment, a DESTROY method 2180 may first write 
audit information to an Audit UDE (blocks 2182, 2184). 
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DESTROY method 2180 may than call a WRITE and/or ACCESS 
method to write information which will corrupt (and thus 
destroy) the header and/or other important parts of the object 
(block 2186). DESTROY method 2180 may then mark one or 
more of the control structures (e.g., the URT) as damaged by 
writing appropriate information to the control structure (blocks 
2188, 2190). DESTROY method 2180, finally, may write 
additional audit information to Audit UDE (blocks 2192, 2194) 
before terminating (terminate point 2196). 

Panic 

Figure 60 is a flowchart of an example of process control 
steps performed by a representative example of a PANIC method 
2200 provided by the preferred embodiment. PANIC method 
2200 may be called when a security violation is detected. PANIC 
method 2200 may prevent the user from further accessing the 
object currently being accessed by, for example, destroying the 
channel being used to access the object and marking one or more 
of the control structures (e.g., the URT) associated with the user 
and object as damaged (blocks 2206, and 2208-2210, 
respectively). Because the control structure is damaged, the VDE 
node will need to contact an administrator to obtain a valid 
control structure(s) before the user may access the same object 
again. When the VDE node contacts the administrator, the 
administrator may request information sufficient to satisfy itself 
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that no security violation occurred, or if a security violation did 
occur, take appropriate steps to ensure that the security violation 
is not repeated. 

Meter 

Figure 61 is a flowchart of an example of process control 
steps performed by a representative example of a METER 
method provided by the preferred embodiment. Although 
METER methods were described above in connection with 
Figures'49, 50 and 51, the METER method 2220 shown in Figure 
61 is possibly a somewhat more representative example. In the 
preferred embodiment, METER method 2220 first primes an 
Audit Trail by accessing a METER Audit Trail UDE (blocks 2222, 
2224). METER method 2220 may then read the DTD for the 
Meter UDE from the secure database (blocks 2226, 2228). 
METER method 2220 may then read the Meter UDE from the 
secure database (blocks 2230, 2232). METER method 2220 next 
may test the obtained Meter UDE to determine whether it has 
expired (decision block 2234). In the preferred embodiment, each 
Meter UDE may be marked with an expiration date. If the 
current date/time is later than the expiration date of the Meter 
UDE ("yes" exit to decision block 2234), then the METER method 
2220 may record a failure in the Audit Record and terminate 
with a failure condition (block 2236, 2238). 
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Assuming the Meter UDE is not yet expired, the meter 
method 2220 may update it using the atomic element and event 
count passed to the METER method from, for example, an 
EVENT method (blocks 2239, 2240). The METER method 2220 
may then save the Meter Use Audit Record in the Meter Audit 
Trail UDE (blocks 2242, 2244), before terminating (at terminate 
point 2246). 

Additional Security Features Provided by the Preferred 
Embodiment 

VDE 100 provided by the preferred embodiment has 
sufficient security to help ensure that it cannot be compromised 
short of a successful "brute force attack," and so that the time 
and cost to succeed in such a "brute force attack" substantially 
exceeds any value to be derived. In addition, the security 
provided by VDE 100 compartmentalizes the internal workings of 
VDE so that a successful "brute force attack" would compromise 
only a strictly bounded subset of protected information, not the 
entire system. 

The following are among security aspects and features 
provided by the preferred embodiment: 

• security of PPE 650 and the processes it performs 

• security of secure database 610 
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• security of encryption/decryption performed by PPE 
650 

• key management; security of encryption/decryption 
keys and shared secrets 

• security of authentication/external communications 

• security of secure database backup 

• secure transportability of VDE internal information 
between electronic appliances 600 

• security of permissions to access VDE secure 
information 

security of VDE objects 300 

• integrity of VDE security. 

Some of these security aspects and considerations are 
discussed above. The following provides an expanded discussion 
of preferred embodiment security features not fully addressed 
elsewhere. 

Management of Keys and Shared Secrets 

VDE 100 uses keys and shared secrets to provide security. 
The following key usage features are provided by the preferred 
embodiment: 

• different cryptosystem/key types 

• secure key length 

• key generation 
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• key "convolution" and key "aging." 
Each of these types are discussed below. 

' A. Public-Key and Symmetric Key Cryptosystems 

The process of disguising or transforming information to 
hide its substance is called encryption. Encryption produces 
"ciphertext." Reversing the encryption process to recover the 
substance from the ciphertext is called "decryption." A 
cryptographic algorithm is the mathematical function used for 
encryption and decryption. 

Most modern cryptographic algorithms use a "key." The 
"key" specifies one of a family of transformations to be provided. 
Keys allow a standard, published and tested cryptographic 
algorithm to be used while ensuring that specific transformations 
performed using the algorithm are kept secret. The secrecy of the 
particular transformations thus depends on the secrecy of the 
key, not on the secrecy of the algorithm. 



There are two general forms of key-based algorithms, 
either or both of which may be used by the preferred embodiment 
PPE 650: 

symmetric; and 

public-key ("PK"). 
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Symmetric algorithms are algorithms where the encryption 
key can be calculated from the decryption key and vice versa. In 
many such systems, the encryption and decryption keys are the 
same. The algorithms, also called "secret-key*, "single key" or 
"shared secret" algorithms, require a sender and receiver to agree 
on a key before ciphertext produced by a sender can be decrypted 
by a receiver. This key must be kept secret. The security of a 
symmetric algorithm rests in the key: divulging the key means 
that anybody could encrypt and decrypt information in such a 
cryptosystem. See Schneier, Applied Cryptography at Page 3. 
Some examples of symmetric key algorithms that the preferred 
embodiment may use include DES, Skipjack/Clipper, IDEA, RC2, 
and RC4. 

In public-key cryptosystems, the key used for encryption is 
different from the key used for decryption. Furthermore, it is 
computationally infeasible to derive one key from the other. The 
algorithms used in these cryptosystems are called "public key" 
because one of the two keys can be made public without 
endangering the security of the other key. They are also 
sometimes called "asymmetric" cryptosystems because they use 
different keys for encryption and decryption. Examples of public- 
key algorithms include RSA, El Gamal and LUC. 
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The preferred embodiment PPE 650 may operate based on 
only symmetric key cryptosystems, based on public-key 
cryptosystems, or based on both symmetric key cryptosystems 
and public-key cryptosystems. VDE 100 does not require any 
specific encryption algorithms; the architecture provided by the 
preferred embodiment may support numerous algorithms 
including PK and/or secret key (non PK) algorithms. In some 
cases, the choice of encryption/decryption algorithm will be 
dependent on a number of business decisions such as cost, 
market demands, compatibility with other commercially 
available systems, export laws, etc. 

Although the preferred embodiment is not dependent on 
any particular type of cryptosystem or encryption/decryption 
algorithm(s), the preferred example uses PK cryptosystems for 
secure communications between PPEs 650, and uses secret key 
cryptosystems for "bulk" encryption/decryption of VDE objects 
300. Using secret key cryptosystems (e.g., DES implementations 
using multiple keys and multiple passes, Skipjack, RC2, or RC4) 
for "bulk" encryption/decryption provides efficiencies in 
encrypting and decrypting large quantities of information, and 
also permits PPEs 650 without PK-capability to deal with VDE 
objects 300 in a variety of applications. Using PK cryptosystems 
for communications may provide advantages such as eliminating 
reliance on secret shared external communication keys to 
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establish communications, allowing for a challenge/response that 
doesn't rely on shared internal secrets to authenticate PPEs 650, 
and allowing for a publicly available "certification" process 
without reliance on shared secret keys. 

Some content providers may wish to restrict use of their 
content to PK implementations. This desire can be supported by 
making the availability of PK capabilities, and the specific nature 
or type of PK capabilities, in PPEs 650 a factor in the registration 
of VDE objects 300, for example, by including a requirement in a 
REGISTER method for such objects in the form of a load module 
that examines a PPE 650 for specific or general PK capabilities 
before allowing registration to continue. 

Although VDE 100 does not require any specific algorithm, 
it is highly desirable that all PPEs 650 are capable of using the 
same algorithm for bulk encryption/decryption. If the bulk 
encryption/decryption algorithm used for encrypting VDE objects 
300 is not scandardized, then it is possible that not all VDE 
electronic appliances 600 will be capable of handling all VDE 
objects 300. Performance differences will exist between different 
PPEs 650 and associated electronic appliances 600 if 
standardized bulk encryption/decryption algorithms are not 
implemented in whole or in part by hardware-based 
encrypt/decrypt engine 522, and instead are implemented in 
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software. In order to support algorithms that are not 
implemented in whole or in part by encrypt/decrypt engine 522, a 
component assembly that implements such an algorithm must be 
available to a PPE 650. 

B. Key Length 

Increased key length may increase security. A "brute- 
force" attack of a cryptosystem involves trying every possible key. 
The longer the key, the more possible keys there are to try. At 
some key length, available computation resources will require an 
unpractically large amount of time for a "brute force" attacker to 
try every possible key: 

VDE 100 provided by the preferred embodiment 
accommodates and can use many different key lengths. The 
length of keys used by VDE 100 in the preferred embodiment is 
determined by the algorithm(s) used for encryption/decryption, 
the level of security desired, and throughput requirements. 
Longer keys generally require additional processing power to 
ensure fast encryption/decryption response times. Therefore, 
there is a tradeoff between (a) security, and (b) processing time 
and/or resources. Since a hardware-based PPE encrypt/decrypt 
engine 522 may provide faster processing than software-based 
encryption/decryption, the hardware-based approach may, in 
general, allow use of longer keys. 
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The preferred embodiment may use a 1024 bit modulus 
(key) RSA cryptosystem implementation for PK 
encryption/decryption, and may use 56-bit DES for "bulk" 
encryption/decryption. Since the 56-bit key provided by standard 
DES may not be long enough to provide sufficient security for at 
least the most sensitive VDE information, multiple DES 
encryptions using multiple passes and multiple DES keys may be 
used to provide additional security. DES can be made 
significantly more secure if operated in a manner that uses 
multiple passes with different keys. For example, three passes 
with 2 or 3 separate keys is much more secure because it 
effectively increases the length of the key. RC2 and RC4 
(alternatives to DES) can be exported for up to 40-bit key sizes, 
but the key size probably needs to be much greater to provide 
even DES level security. The 80-bit key length provided by 
NSA's Skipjack may be adequate for most VDE security needs. 

The capability of downloading code and other information 
dynamically into PPE 650 allows key length to be adjusted and 
changed dynamically even after a significant number of VDE 
electronic appliances 600 are in use. The ability of a VDE 
administrator to communicate with each PPE 650 efficiently 
makes such after-the-fact dynamic changes both possible and 
cost-effective. New or modified cryptosystems can be downloaded 
into existing PPEs 650 to replace or add to the cryptosystem 
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repertoire available within the PPE, allowing older PPEs to 
maintain compatibility with newer PPEs and/or newly released 
VDE objects 300 and other VDE-protected information. For 
example, software encryption/decryption algorithms may be 
downloaded into PPE 650 at any time to supplement the 
hardware-based functionality of encrypt/decrypt engine 522 by 
providing different key length capabilities. To provide increased 
flexibility, PPE encrypt/decrypt engine 522 may be configured to 
anticipate multiple passes and/or variable and/or longer key 
lengths. In addition, it may be desirable to provide PPEs 650 
with the capability to internally generate longer PK keys. 

C. Key Generation 

Key generation techniques provided by the preferred 
embodiment permit PPE 650 to generate keys and other 
information that are "known" only to it. 

The security of encrypted information rests in the security 
of the key used to encrypt it. If a cryptographically weak process 
is used to generate keys, the entire security is weak. Good keys 
are random bit strings so that every possible key in the key space 
is equally likely. Therefore, keys should in general be derived 
from a reliably random source, for example, by a 
cryptographically secure pseudo-random number generator 
seeded from such a source. Examples of such key generators are 
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described in Schneier, Applied Cryptography (John Wiley and 
Sons, 1994), chapter 15. If keys are generated outside a given 
PPE 650 (e.g., by another PPE 650), they must be verified to 
ensure they come from a trusted source before they can be used. 
"Certification" may be used to verify keys. 

The preferred embodiment PPE 650 provides for the 
automatic generation of keys. For example, the preferred 
embodiment PPE 650 may generate its own pubUc/private key 
pair for use in protecting PK-based external communications and 
for other reasons. A PPE 650 may also generate its own 
symmetric keys for various purposes during and after 
initialization. Because a PPE 650 provides a secure 
environment, most key generation in the preferred embodiment 
may occur within the PPE (with the possible exception of initial 
PPE keys used at manufacturing or installation time to allow a 
PPE to authenticate initial download messages to it). 

Good key generation relies on randomness. The preferred 
embodiment PPE 650 may, as mentioned above in connection 
with Figure 9, includes a hardware-based random number 
generator 542 with the characteristics required to generate 
reliable random numbers. These random numbers may be used 
to "seed" a cryptographically strong pseudo-random number 
generator (e.g., DES operated in Output Feedback Mode) for 
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generation of additional key values derived from the random 
seed. In the preferred embodiment, random number generator 
542 may consist of a "noise diode" or other physically-based 
source of random values (e.g., radioactive decay). 

If no random number generator 542 is available in the PPE 
650, the SPE 503 may employ a cryptographic algorithm (e.g., 
DES in Output Feedback Mode) to generate a sequence of 
pseudo-random values derived from a secret value protected 
within the SPE. Although these numbers are pseudo-random 
rather than truly random, they are cryptographically derived 
from a value unknown outside the SPE 503 and therefore may be 
satisfactory in some applications. 

In an embodiment incorporating an HPE 655 without an 
SPE 503, the random value generator 565 software may derive 
reliably random numbers from unpredictable external physical 
events (e.g., high-resolution timing of disk I/O completions or of 
user keystrokes at an attached keyboard 612). 

Conventional techniques for generating PK and non-PK 
keys based upon such "seeds" may be used. Thus, if performance 
and manufacturing costs permit, PPE 650 in the preferred 
embodiment will generate its own public/private key pair based 
on such random or pseudo-random "seed" values. This key pair 
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may then be used for external communications between the PPE 
650 that generated the key pair and other PPEs that wish to 
communicate with it. For example, the generating PPE 650 may 
reveal the public key of the key pair to other PPEs. This allows 
other PPEs 650 using the public key to encrypt messages that 
may be decrypted only by the generating PPE (the generating 
PPE is the only PPE that "knows" the corresponding "private 
key"). Similarly, the generating PPE 650 may encrypt messages 
using its private key that, when decrypted successfully by other 
PPEs with the generating PPE's public key, permit the other 
PPEs to authenticate that the generating PPE sent the message. 

Before one PPE 650 uses a public key generated by 
another PPE, a public key certification process should be used to 
provide authenticity certificates for the public key. A public-key 
certificate is someone's public key "signed" by a trustworthy 
entity such as an authentic PPE 650 or a VDE administrator. 
Certificates are used to thwart attempts to convince a PPE 650 
that it is communicating with an authentic PPE when it is not 
(e.g., it is actually communicating with a person attempting to 
break the security of PPE 650). One or more VDE administrators 
in the preferred embodiment may constitute a certifying 
authority. By "signing" both the public key generated by a PPE 
650 and information about the PPE and/or the corresponding 
VDE electronic appliance 600 (e.g., site ID, user ID, expiration 
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date, name, address, etc.), the VDE administrator certifying 
authority can certify that information about the PPE and/or the 
VDE electronic appliance is correct and that the public key 
belongs to that particular VDE mode. 

Certificates play an important role in the trustedness of 
digital signatures, and also are important in the public-key 
authentication communications protocol (to be discussed below). 
In the preferred embodiment, these certificates may include 
information about the trustedness/level of security of a particular 
VDE electronic appliance 600 (e.g., whether or not it has a 
hardware-based SPE 503 or is instead a less trusted software 
emulation type HPE 655) that can be used to avoid transmitting 
certain highly secure information to less trusted/secure VDE 
installations. 

Certificates can also play an important role in 
decommissioning rogue users and/or sites. By including a site 
and/or user ID in a certificate, a PPE can evaluate this 
information as an aspect of authentication. For example, if a 
VDE administrator or clearinghouse encounters a certificate 
bearing an ID (or other information) that meets certain criteria 
(e.g., is present on a list of decommissioned and/or otherwise 
suspicious users and/or sites), they may choose to take actions 
based on those criteria such as refusing to communicate, 
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communicating disabling information, notifying the user of the 
condition, etc. Certificates also typically include an expiration 
date to ensure that certificates must be replaced periodically, for 
example, to ensure that sites and/or users must stay in contact 
with a VDE administrator and/or to allow certification keys to be 
changed periodically. More than one certificate based on 
different keys may be issued for sites and/or users so that if a 
given certification key is compromised, one or more "backup" 
certificates may be used. If a certification key is compromised, A 
VDE administrator may refuse to authenticate based on 
certificates generated with such a key, and send a signal after 
authenticating with a "backup" certificate that invalidates all use 
of the compromised key and all certificates associated with it in 
further interactions with VDE participants. A new one or more 
"backup" certificates and keys may be created and sent to the 
authenticated site/user after such a compromise. 

If multiple certificates are available, some of the 
certificates may be reserved as backups. Alternatively or in 
addition, one certificate from a group of certificates may be 
selected (e.g., by using RNG 542) in a given authentication, 
thereby reducing the likelihood that a certificate associated with 
a compromised certification key will be used. Still alternatively, 
more than one certificate may be used in a given authentication. 
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To guard against the possibility of compromise of the 
certification algorithm (e.g., by an unpredictable advance in the 
mathematical foundations on which the algorithm is based), 
distinct algorithms may used for different certificates that are 
based on different mathematical foundations. 

Another technique that may be employed to decrease the 
probability of compromise is to keep secret (in protected storage 
in the PPE 650) the "public" values on which the certificates are 
based, thereby denying an attacker access to values that may aid 
in the attack. Although these values are nominally "public," they 
need be known only to those components which actually validate 
certificates (i.e., the PPE 650). 

In the preferred embodiment, PPE 650 may generate its 
own certificate, or the certificate may be obtained externally, 
such as from a certifying authority VDE administrator. 
Irrespective of where the digital certificate is generated, the 
certificate is eventually registered by the VDE administrator 
certifying authority so that other VDE electronic appliances 600 
may have access to (and trust) the public key. For example, PPE 
650 may communicate its public key and other information to a 
certifying authority which may then encrypt the public key and 
other information using the certifying authority's private key. 
Other installations 600 may trust the "certificate" because it can 
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be authenticated by using the certifying authority's public key to 
decrypt it. As another example, the certifying authority may 
encrypt the public key it receives from the generating PPE 650 
and use it to encrypt the certifying authority's private key. The 
certifying authority may then send this encrypted information 
back to the generating PPE 650. The generating PPE 650 may 
then use the certifying authority's private key to internally create 
a digital certificate, after which it may destroy its copy of the 
certifying authority's private key. The generating PPE 650 may 
then send out its digital certificate to be stored in a certification 
repository at the VDE administrator (or elsewhere) if desired. 
The certificate process can also be implemented with an external 
key pair generator and certificate generator, but might be 
somewhat less secure depending on the nature of the secure 
facility. In such a case, a manufacturing key should be used in 
PPE 650 to limi t exposure to the other keys involved. 

A PPE 650 may need more than one certificate. For 
example, a certificate may be needed to assure other users that a 
PPE is authentic, and to identify the PPE. Further certificates 
may be needed for individual users of a PPE 650. These 
certificates may incorporate both user and site information or 
may only include user information. Generally, a certifying 
authority will require a valid site certificate to be presented prior 
to creating a certificate for a given user. Users may each require 
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their own public key/private key pair in order to obtain 
certificates. VDE administrators, clearinghouses, and other 
participants may normally require authentication of both the site 
(PPE 650) and of the user in a communication or other 
interaction. The processes described above for key generation 
and certification for PPEs 650 may also be used to form site/user 
certificates or user certificates. 

Certificates as described above may also be used to certify 
the origin of load modules 1100 and/or the authenticity of 
administrative operations. The security and assurance 
techniques described above may be employed to decrease the 
probability of compromise for any such certificate (including 
certificates other than the certificate for a VDE electronic 
appliance 600's identity). 

D. Key Aging and Convolution 

PPE 650 also has the ability in the preferred embodiment 
to generate secret keys and other information that is shared 
between multiple PPEs 650. In the preferred embodiment, such 
secret keys and other information may be shared between 
multiple VDE electronic appliances 600 without requiring the 
shared secret information to ever be communicated explicitly 
between the electronic appliances. More specifically, PPE 650 
uses a technique called "key convolution" to derive keys based on 
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a deterministic process in response to seed information shared 
between multiple VDE electronic appliances 600. Since the 
multiple electronic appliances 600 "know" what the "seed" 
information is and also "know" the deterministic process used to 
generate keys based on this information, each of the electronic 
appliances may independently generate the "true key." This 
permits multiple VDE electronic appliances 600 to share a 
common secret key without potentially compromising its security 
by communicating it over an insecure channel 

No encryption key should be used for an inde finit e period. 
The longer a key is used, the greater the chance that it may be 
compromised and the greater the potential loss if the key is 
compromised but still in use to protect new information. The 
longer a key is used, the more information it may protect and 
therefore the greater the potential rewards for someone to spend 
the effort necessary to break it. Further, if a key is used for a 
long time, there may be more ciphertext available to an attacker 
attempting to break the key using a ciphertext-based attack. See 
Schneier at 150-151. Key convolution in the preferred 
embodiment provides a way to efficiently change keys stored in 
secure database 610 on a routine periodic or other basis while 
simplifying key management issues surrounding the change of 
keys. In addition, key convolution may be used to provide "time 
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aged keys" (discussed below) to provide "expiration dates" for key 
usage and/or validity. 

Figure 62 shows an example implementation of key 
convolution in the preferred embodiment. Key convolution may 
be performed using a combination of a site ID 2821 and the high- 
order bits of the RTC 528 to yield a site-unique value "V" that is 
time-dependent on a large scale (e.g., hours or days). This value 
"V" may be used as the key for an encryption process 2871 that 
transforms a convolution seed value 2861 into a "current 
convolution key" 2862. The seed value 2861 may be a universe- 
wide or group-wide shared secret value, and may be stored in 
secure key storage (e.g., protected memory within PPE 650). The 
seed value 2861 is installed during the manufacturing process 
and may be updated occasionally by a VDE administrator. There 
may be a plurality of seed values 2861 corresponding to different 
sets of objects 300. 

The current convolution key 2862 represents an encoding 
of the site ID 2821 and current time. This transformed value 
2862 may be used as a key for another encryption process 2872 
to transform the stored key 810 in the object's PERC 808 into the 
true private body key 2863 for the object's contents. 
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The "convolution function" performed by blocks 2861, 2871 
may, for example, be a one-way function that can be performed 
independently at both the content creator's site and at the 
content user's site. If the content user does not use precisely the 
same convolution function and precisely the same input values 
(e.g., time and/or site and/or other information) as used by the 
content creator, then the result of the convolution function 
performed by the content user will be different from the content 
creator's result. If the result is used as a symmetrical key for 
encryption by the content creator, the content user will not be 
able to decrypt unless the content user's result is the same as the 
result of the content creator. 

The time component for input to the key convolution 
function may be derived from RTC 528 (care being taken to 
ensure that slight differences in RTC synchronization between 
VDE electronic appliances will not cause different electronic 
appliances to use different time components). Different portions 
of the RTC 528 output may be used to provide keys with different 
valid durations, or some tolerance can be built into the process to 
try several different key values. For example, a "time 
granularity" parameter can be adjusted to provide time tolerance 
in terms of days, weeks, or any other time period. As one 
example, if the "time granularity" is set to 2 days, and the 
tolerance is ±2 days, then three real-time input values can be 
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tried as input to the convolution algorithm. Each of the resulting 
key values may be tried to determine which of the possible keys 
is actually used. In this example, the keys will have only a 4 day 
life span. 

Figure 63 shows how an appropriate convoluted key may 
be picked in order to compensate for skew between the user's 
RTC 528 and the producer's RTC 528. A sequence of convolution 
keys 2862 (a-e) may be generated by using different input values 
2881(a-e), each derived from the site ID 2821 and the RTC 528 
value plus or minus a differential (e.g., -2 days, -1 days, no delta, 
+1 days, +2 days). The convolution steps 287 1( a-e) are used to 
generate the sequence of keys 2862(a-e). 

Meanwhile, the creator site may use the convolution step 
2871(z) based on his RTC 528 value (adjusted to correspond to 
the intended validity time for the key) to generate a convoluted 
key 2862(z), which may then be used to generate the content key 
2863 in the object's PERC 808. To decrypt the object's content, 
the user site may use each of its sequence of convolution keys 
2862 (a-e) to attempt to generate the master content key 810. 
When this is attempted, as long as the RTC 538 of the creator 
site is within acceptable tolerance of the RTC 528 at the user site, 
one of keys 2862(a-e) will match key 2862(z) and the decryption 
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will be successful. In this example, matching is determined by 
validity of decrypted output, not by direct comparison of keys. 

Key convolution as described above need not use both site 
ID and time as a value. Some keys may be generated based on 
current real time, other keys might be generated on site ED, and 
still other keys might be generated based on both current real- 
time and site ID. 

Key convolution can be used to provide "time-aged" keys. 
Such "time-aged" keys provide an automatic mechanism for 
allowing keys to expire and be replaced by "new" keys. They 
provide a way to give a user time-limited rights to make time- 
limited use of an object, or portions of an object, without 
requiring user re-registration but retaining significant control in 
the hands of the content provider or administrator. If secure 
database 610 is sufficiently secure, similar capabilities can be 
accomplished by checking an expiration date/time associated 
with a key, but this requires using more storage space for each 
key or group of keys. 

In the preferred embodiment, PERCs 808 can include an 
expiration date and/or time after which access to the VDE- 
protected information they correspond to is no longer authorized. 
Alternatively or in addition, after a duration of time related to 
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some aspect of the use of the electronic appliance 600 or one or 
more VDE objects 300, a PERC 808 can force a user to send audit 
history information to a clearinghouse, distributor, client 
administrator, or object creator in order to regain or retain the 
right to use the object(s). The PERC 808 can enforce such time- 
based restrictions by checking/enforcing parameters that limit 
key usage and/or availability past time of authorized use. "Time 
aged" keys may be used to enforce or enhance this type of time- 
related control of access to VDE protected information. 

"Time aged" keys can be used to encrypt and decrypt a set 
of information for a limited period of time, thus requiring 
re-registration or the receipt of new permissions or the passing of 
audit information, without which new keys are not provided for 
user use. Time aged keys can also be used to improve system 
security since one or more keys would be automatically replaced 
based on the time ageing criteria — and thus, cracking secure 
database 610 and locating one or more keys may have no real 
value. Still another advantage of using time aged keys is that 
they can be generated dynamically — thereby obviating the need 
to store decryption keys in secondary and/or secure memory. 

A "time aged key" in the preferred embodiment is not a 
"true key" that can be used for encryption/decryption, but rather 
is a piece of information that a PPE 650, in conjunction with 
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other information, can use to generate a "true key." This other 
information can be time-based, based on the particular "ID" of 
the PPE 650, or both. Because the "true key" is never exposed 
but is always generated within a secure PPE 650 environment, 
and because secure PPEs are required to generate the "true key," 
VDE 100 can use "time aged" keys to significantly enhance 
security and flexibility of the system. 

The process of "aging" a key in the preferred embodiment 
involves generating a time-aged "true key" that is a function of: 
(a) a "true key," and (b) some other information (e.g., real time 
parameters, site ID parameters, etc.) This information is 
combined/transformed (e.g., using the "key convolution" 
techniques discussed above) to recover or provide a "true key." 
Since the "true key" can be recovered, this avoids having to store 
the "true key" within PERC 808, and allow different "true keys" 
to correspond to the same information within PERC 808. 
Because the "true key" is not stored in the PERC 808, access to 
the PERC does not provide access to the information protected by 
the "true key." Thus, "time aged" keys allows content 
creators/providers to impose a limitation (e.g., site based and/or 
time based) on information access that is, in a sense, "external of £ 
or auxiliary to the permissioning provided by one or more PERCs 
808. For example, a "time aged" key may enforce an additional 
time limitation on access to certain protected information, this 
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additional time limitation being independent of any information 
or permissioning contained within the PERC 808 and being 
instead based on one or more time and/or site ID values. 

As one example, time-aged decryption keys may be vised to 
allow the purchaser of a "trial subscription" of an electronically 
published newspaper to access each edition of the paper for a 
period of one week, after which the decryption keys will no longer 
work. In this example, the user would need to purchase one or 
more new PERCs 808, or receive an update to an existing one or 
more permissions records, to access editions other than the ones 
from that week. Access to those other editions which might be 
handled with a totally different pricing structure (e.g., a "regular" 
subscription rate as opposed to a free or minimal "trial" 
subscription rate). 

In the preferred embodiment, time-aged-based "true keys" 
can be generated using a one-way or invertible "key convolution" 
function. Input parameters to the convolution function may 
include the supplied time-aged keys; user and/or site specific 
values; a specified portion (e.g., a certain number of high order 
bits) of the time value from an RTC 528 (if present) or a value 
derived from such time value in a predefined manner; and a block 
or record identifier that may be used to ensure that each time 
aged key is unique. The output of the "key convolution" function 
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may be a "true key" that is used for decryption purposes until 
discarded. Running the function with a time-aged key and 
inappropriate time values typically yields a useless key that will 
not decrypt. 

Generation of a new time aged key can be triggered based 
on some value of elapsed, absolute or relative time (e.g., based on 
a real time value from a clock such as RTC 528). At that time, 
the convolution would produce the wrong key and decryption 
could not occur until the time-aged key is updated. The criteria 
used to determine when a new "time aged key" is to be created 
may itself be changed based on time or some other input variable 
to provide yet another level of security. Thus, the convolution 
function and/or the event invoking it may change, shift or employ 
a varying quantity as a parameter. 

One example of the use of time-aged keys is as follows: 

1) A creator makes a "true" key, and encrypts content 
with it. 

2) A creator performs a "reverse convolution" to yield a 
"time aged key" using, as input parameters to the 
"reverse convolution": 

a) the "true" key, 
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b) 



a time parameter (e.g., valid high-order 



time bits of RTC 528), and 



0 



optional other information (e.g., site ID 



and/or user ID). 



3) The creator distributes the "time-aged key" to 
content users (the creator may also need to 
distribute the convolution algorithm and/or 
parameters if she is not using a convolution 
algorithm already available to the content users' 
PPE 650). 

4) The content user's PPE 650 combines; 

a) "time-aged" key 

b) high-order time bits 

c) required other information (same as 2c). 

It performs a convolution function (i.e., the inverse of "reverse 
convolution" algorithm in step (2) above) to obtain the "true" key. 
If the supplied time and/or other information is "wrong," the 
convolution function will not yield the "true" key, and therefore 
content cannot be decrypted. 

Any of the key blocks associated with VDE objects 300 or 
other items can be either a regular key block or a time-aged key 
block, as specified by the object creator during the object 
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configuration process, or where appropriate, a distributor or 
client a dminis trator. 

"Time aged" keys can also be used as part of protocols to 
provide secure communications between PPEs 650. For example, 
instead of providing "true" keys to PPE 650 for communications, 
VDE 100 may provide only "partial" communication keys to the 
PPE. These "partial" keys may be provided to PPE 650 during 
initialization, for example. A predetermined algorithm may 
produce "true keys" for use to encrypt/decrypt information for 
secure communications. The predetermined algorithm can "age" 
these keys the same way in all PPEs 650, or PPEs 650 can be 
required to contact a VDE administrator at some predetermined 
time so a new set of partial communications keys can be 
downloaded to the PPEs. If the PPE 650 does not generate or 
otherwise obtain -"new" partial keys, then it will be disabled from 
communicating with other PPEs (a further, "fail safe" key may be 
provided to ensure that the PPE can communicate with a VDE 
administrator for reinitialization purposes). Two sets of partial 
keys can be maintained within a PPE 650 to allow a fixed 
amount of overlap time across all VDE appliances 600. The older 
of the two sets of partial keys can be updated periodically. 

The following additional types of keys (to be discussed 
below) can also be "aged" in the preferred embodiment: 
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individual message keys (i.e., keys used for a particular 
message), 

administrative, stationary and travelling object shared 
keys, 

secure database keys, and 
private body and content keys. 

Initial Installation Key Management 

Figure 64 shows the flow of universe- wide, or "master," 
keys during creating of a PPE 650. In the preferred embodiment, 
the PPE 650 contains a secure non-volatile key storage 2802 (e.g. 
SPU 500 non-volatile RAM 534 B or protected storage 
maintained by HPE 655) that is initialized with keys generated 
by the manufacturer and by the PPE itself. 

The manufacturer possesses (i.e., knows, and protects from 
disclosure or modification) one or more public key 2811/private 
key 2812 key pairs used for signing and validating site 
identification certificates 2821. For each site, the manufacturer 
generates a site ID 2821 and list of site characteristics 2822. In 
addition, the manufacturer possesses the public keys 2813, 2814 
for validating load modules and initialization code downloads. To 
enhance security, there may be a plurality of such certification 
keys, and each PPE 650 may be initialized using only a subset of 
such keys of each type. 
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As part of the initialization process, the PPE 650 may 
generate internally or the manufacturer may generate and 
supply, one or more pairs of site-specific public keys 2815 and 
private keys 2816. These are used by the PPE 650 to prove its 
identity. Similarly, site-specific database key(s) 2817 for the site 
are generated, and if needed (i.e., if a Random Number Generator 
542 is not available), a random initialization seed 2818 is 
generated. 

The initialization may begin by generating site ID 2821 
and characteristics 2822 and the site public key 2815/private key 
2816 pair(s). These values are combined and may be used to 
generate one or more site identity certificates 2823. The site 
identity certificates 2823 may be generated by the public key 
generation process 2804, and may be stored both in the PPE's 
protected key storage 2802 and in the manufacturer's VDE site 
certificate database 2803. 

The certification process 2804 may be performed either by 
the manufacturer or internally to the PPE 650. If performed by 
the PPE 650, the PPE will temporarily receive the identity 
certification private key(s) 2812, generate the certificate 2823, 
store the certificate in local key storage 2802 and transmit it to 
the manufacturer, after which the PPE 650 must erase its copy of 
the identity certification private key(s) 2812. 
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Subsequently, initialization may require generation, by the 
PPE 650 or by the manufacturer, of site-specific database key(s) 
2817 and of site-specific seed value(s) 2818, which are stored in 
the key storage 2802. In addition, the download certification 
key(s) 2814 and the load module certification key(s) 2813 may be 
supplied by the manufacturer and stored in the key storage 2802. 
These may be used by the PPE 650 to validate all further 
communications with external entities. 

At this point, the PPE 650 may be further initialized with 
executable code and data by downloading information certified by 
the load module key(s) 2813 and download key(s) 2814. In the 
preferred embodiment, these keys may be used to digitally sign 
data to be loaded into the PPE 650, guaranteeing its validity, and 
additional key(s) encrypted using the site-specific public key(s) 
2815 may be used to encrypt such data and protect it from 
disclosure. 

Installation and Update Key Management 

Figure 65 illustrates an example of further key installation 
either by the manufacturer or by a subsequent update by a VDE 
administrator. The manufacturer or administrator may supply 
initial or new values for private header key(s) 2831, external 
communication key(s) 2832, administrative object keys 2833, or 
other shared key(s) 2834. These keys may be universe-wide in 
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the same sense as the global certification keys 2811, 2813, and 
2814, or they may be restricted to use within a defined group of 
VDE instances. 

To perform this installation, the installer retrieves the 
destination site's identity certificate(s) 2823, and from that 
extracts the site public key(s) 2815. These key(s) may be used in 
an encryption process 2841 to protect the keys being installed. 
The key(s) being installed are then transmitted inside the 
destination site's PPE 650. Inside the PPE 650, the decryption 
process 2842 may use the site private key(s) 2816 to decrypt the 
transmission. The PPE 650 then stores the installed or updated 
keys in its key storage 2802. 

Object-Specific Key Use 

Figures 66 and 67 illustrate the use of keys in protecting 
data and control information associated with VDE objects 300. 

Figure 66 shows use of a stationary content object 850 
whose control information is derived from an administrative 
object 870. The objects may be received by the PPE 650 (e.g., by 
retrieval from an object repository 728 over a network or 
retrieved from local storage). The administrative object 
decryption process 2843 may use the private header key(s) 2815 
to decrypt the administrative object 870, thus retrieving the 
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PERC 808 governing access to the content object 850. The 
private body key(s) 810 may then be extracted from the PERC 
808 and used by the content decryption process 2845 to make the 
content available outside the PPE 650. In addition, the database 
key(s) 2817 may be used by the encryption process 2844 to 
prepare the PERC for storage outside the PPE 650 in the secure 
database 610. In subsequent access to the content object 850, the 
PERC 808 may be retrieved from the secure database 610, 
decrypted with database key(s) 2817, and used directly, rather 
than being extracted from administrative object 870. 

Figure 67 shows the similar process involving a traveling 
object 860. The principal distinction between Figures 66 and 67 
is that the PERC 808 is stored directly within the traveling object 
860, and therefore may be used immediately after the decryption 
process 2843 to provide a private header key(s) 2831. This 
private header key 2831is used to process content within the 
traveling object 860. 

Secret-Key Variations 

Figures 64 through 67 illustrate the preferred public-key 
embodiment, but may also be used to help understand the secret- 
key versions. In secret-key embodiments, the certification 
process and the public key encryptions/decryptions are replaced 
with private-key encryptions, and the public key/private-key 
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pairs are replaced with individual secret keys that are shared 
between the PPE 650 instance and the other parties (e.g., the 
load module suppliers), the PPE manufacturer). In addition, the 
certificate generation process 2804 is not performed in secret-key 
embodiments, and no site identity certificates 2823 or VDE 
certificate database 2803 exist. 

Key Types 

The detailed descriptions of key types below further 
explain secret-key embodiments; this summary is not intended as 
a complete description. The preferred embodiment PPE 650 can 
use different types of keys and/or different "shared secrets" for 
different purposes. Some key types apply to a Public-Key/Secret 
Key implementation, other keys apply to a Secret Key only 
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implementation, and still other key types apply to both. The 
following table lists examples of various key and "shared secret" 
information used in the preferred embodiment, and where this 
information is used and stored: 



Key/Secret Information Type 


Used in PK or Non- 
PK 


Example Storage Location(a) 


Master Key(s) (may include 
some of the specific keys 
mentioned below) 


Both 


PPE 

Manufacturing facility 
VDE administrator 


Manufacturing Key 


Both (PK optional) 


PPE (PK case) 
Manufacturing facility 


Certification key pair 


PK 


PPE 

Certification reoositorv 


Public/private key pair 


PK 


PPE 

Certification repository (Public Key 
only) 


Initial secret key 


Non-PK 


PPE 


PPE manufacturing ID 


Non-PK 


PPE 


Site ID, shared code, shared 
kevs and shared secrets 


Both 


PPE 


Download authorization key 


Both 


PPE 


External communication keys 
and other info 


Both 


PPE 

Secure Database 


Administrative obiect keys 


Both 


Permission record 


Stationary object kevs 


Both 


Permission record 


Traveling object shared keys 


Both 


Permission record 


Secure database kevs 


Both 


PPE 


Private body keys 


Both 


Secure database 
Some objects 


Content keys 


Both 


Secure database 
Some objects 


Authorization shared secrets 


Both 


Permission record 


Secure Database Back up 
kevs 


Both 


PPE 

Secure database 



620 



WO 96/27155 



PCI7US96/02303 



Master KeyB 

A "master" key is a key used to encrypt other keys. An 
initial or "master" key may be provided within PPE 650 for 
communicating other keys in a secure way. During initialization 
of PPE 650, code and shared keys are downloaded to the PPE. 
Since the code contains secure convolution algorithms and/or 
coefficients, it is comparable to a "master key." The shared keys 
may also be considered "master keys." 

If public-key cryptography is used as the basis for external 
communication with PPE 650, then a master key is required 
during the PPE Public-key pair certification process. This 
master key may be, for example, a private key used by the 
manufacturer or VDE administrator to establish the digital 
certificate (encrypted public key and other information of the 
PPE), or it may, as another example, be a private key used by a 
VDE administrator to encrypt the entries in a certification 
repository. Once certification has occurred, external 
communications between PPEs 650 may be established using the 
certificates of communicating PPEs. 

If shared secret keys are used as the basis for external 
communications, then an initial secret key is required to 
establish external communications for PPE 650 initialization. 
This initial secret key is a "master key" in the sense that it is 



621 



WO 96/27155 



PCTAJS96/02303 



used to encrypt other keys. A set of shared partial external 
communications keys (see discussion above) may be downloaded 
during the PPE initialization process, and these keys are used to 
establish subsequent external PPE co mmu nications 

Manufacturing Key 

A manufacturing key is used at the time of PPE 
manufacture to prevent knowledge by the manufacturing staff of 
PPE-specific key information that is downloaded into a PPE at 
initialization time. For example, a PPE 650 that operates as part 
of the manufacturing facility may generate information for 
download into the PPE being initialized. This information must 
be encrypted during communication between the PPEs 650 to 
keep it confidential, or otherwise the manufacturing staff could 
read the information. A manufacturing key is used to protect the 
information. The manufacturing key may be used to protect 
various other keys downloaded into the PPE such as, for 
example, a certification private key, a PPE public/private key 
pair, and/or other keys such as shared secret keys specific to the 
PPE. Since the manufacturing key is vised to encrypt other keys, 
it is a "master key." 

A manufacturing key may be public-key based, or it may be 
based on a shared secret. Once the information is downloaded, 
the now-initialized PPE 650 can discard (or simply not use) the 
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manufacturing key. A manufacturing key may be hardwired into 
PPE 650 at manufacturing time, or sent to the PPE as its first 
key and discarded after it is no longer needed. As indicated in 
the table above and in the preceding discussion, a manufacturing 
key is not required if PK capabilities are included in the PPE. 

Certification Key Pair 

A certification key pair may be used as part of a 
"certification" process for PPEs 650 and VDE electronic 
appliances 600. This certification process in the preferred 
embodiment may be used to permit a VDE electronic appliance to 
present one or more "certificates" authenticating that it (or its 
key) can be trusted. As described above, this "certification" 
process may be used by one PPE 650 to "certify" that it is an 
authentic VDE PPE, it has a certain level of security and 
capability set (e.g., it is hardware based rather than merely 
software based), etc. Briefly, the "certification" process may 
involve using a certificate private key of a certification key pair to 
encrypt a message including another VDE node's public-key. The 
private key of a certification key pair is preferably used to 
generate a PPE certificate. It is used to encrypt a public-key of 
the PPE. A PPE certificate can either be stored in the PPE, or it 
may be stored in a certification repository. 



623 



WO 96/27155 



PCT7US96/02303 



Depending on the authentication technique chosen, the 
public key and the private key of a certification key pair may 
need to be protected. In the preferred embodiment, the 
certification public key(s) is distributed amongst PPEs such that 
they may make use of them in decrypting certificates as an 
aspect of authentication. Since, in the preferred embodiment, 
this public key is used inside a PPE 650, there is no need for this 
public key to be available in plaintext, and in any event it is 
important that such key be maintained and transmitted with 
integrity (e.g., during initialization and/or update by a VDE 
administrator). If the certification public key is kept confidential 
(i.e., only available in plaintext inside the PPE 650), it may make 
cracking security much more difficult. The private key of a 
certification key pair should be kept confidential and only be 
stored by a certifying authority (i.e., should not be distributed). 

In order to allow, in the preferred embodiment, the ability 
to differentiate installations with different levels/degrees of 
trustedness/security, different certification key pairs may be used 
(e.g., different certification keys may be used to certify SPEs 503 
then are used to certify HPEs 655). 

PPE Public/Private Key Pair 

In the preferred embodiment, each PPE 650 may have its 
own unique "device" (and/or user) public/private key pair. 
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Preferably, the private key of this key pair is generated within 
the PPE and is never exposed in any form outside of the PPE. 
Thus, in one embodiment, the PPE 650 may be provided with an 
internal capability for generating key pairs internally. If the 
PPE generates its own public-key crypto-system key pairs 
internally, a manufacturing key discussed above may not be 
needed. If desired, however, for cost reasons a key pair may be 
exposed only at the time a PPE 650 is manufactured, and may be 
protected at that time using a manufacturing key. Allowing PPE 
650 to generate its public key pair internally allows the key pair 
to be concealed, but may in some applications be outweighed by 
the cost of putting a public-key key pair generator into PPE 650. 

Initial Secret Key 

The initial secret key is used as a master key by a secret 
key only based PPE 650 to protect information downloaded into 
the PPE during initialization. It is generated by the PPE 650, 
and is sent from the PPE to a secure manufacturing database 
encrypted using a manufacturing key. The secure database 
sends back a unique PPE manufacturing ID encrypted using the 
initial secret key in response. 

The initial secret key is likely to be a much longer key than 
keys used for "standard" encryption due to its special role in PPE 
initialization. Since the resulting decryption overhead occurs 
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only during the initialization process, multiple passes through 
the decryption hardware with selected portions of this key are 
tolerable. 

PPE Manufacturing ID 

The PPE manufacturing ID is not a "key," but does fall 
within the classic definition of a "shared secret." It preferably 
uniquely identifies a PPE 650 and may be used by the secure 
database 610 to determine the PPE's initial secret key during- the 
PPE initialization process. 

Site ID, Shared Code, Shared Keys and Shared Secrets 

The VDE site ID along with shared code, keys and secrets 
are preferably either downloaded into PPE 650 during the PPE 
initialization process, or are generated internally by a PPE as 
part of that process. In the preferred embodiment, most or all of 
this information is downloaded. 

The PPE site ID uniquely identifies the PPE 650. The site 
ED is preferably unique so as to uniquely identify the PPE 650 
and distinguish that PPE from all other PPEs. The site ID in the 
preferred embodiment provides a unique address that may be 
used for various purposes, such as for example to provide 
"address privacy" functions. In some cases, the site ED may be 
the public key of the PPE 650. In other cases, the PPE site ID 
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may be assigned during the manufacturing and/or initialization 
process. In the case of a PPE 650 that is not public-key-capable, 
it would not be desirable to use the device secret key as the 
unique site ID because this would expose too many bits of the 
key — and therefore a different information string should be used 
as the site ID. 

Shared code comprises those code fragments that provide 
at least a portion of the control program for the PPE 650. In the 
preferred embodiment, a basic code fragment is installed during 
PPE manufacturing that permits the PPE to bootstrap and begin 
the initialization process. This fragment can be replaced during 
the initialization process, or during subsequent download 
processing, with updated control logic. 

Shared keys may be downloaded into PPE 650 during the 
initialization process. These keys may be used, for example, to 
decrypt the private headers of many object structures. 

When PPE 650 is operating in a secret key only mode, the 
initialization and download processes may import shared secrets 
into the PPE 650. These shared secrets may be used during 
communications processes to permit PPEs 650 to authenticate 
the identity of other PPEs and/or users. 



627 



WO 96/27155 



PCT/US96/02303 



Download Authorization Key 

The download authorization key is received by PPE 650 
during the initialization download process. It is used to authorize 
farther PPE 650 code updates, key updates, and may also be 
used to protect PPE secure database 610 backup to allow 
recovery by a VDE administrator (for example) if the PPE fails. 
It may be used along with the site ID, time and convolution 
algorithm to derive a site ID specific key. The download 
authorization key may also be used to encrypt the key block used 
to encrypt secure database 610 backups. It may also be used to 
form a site specific key that is used to enable future downloads to 
the PPE 650. This download authorization key is not shared 
among all PPEs 650 in the preferred embodiment; it is specific to 
functions performed by authorized VDE administrators. 

External Communications KeyB and Related Secret and Public 
Information 

There are several cases where keys are required when 
PPEs 650 communicate. The process of establishing secure 
communications may also require the use of related public and 
secret information about the communicating electronic 
appliances 600. The external communication keys and other 
information are used to support and authenticate secure 
communications. These keys comprise a public-key pair in the 
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preferred embodiment although shared secret keys may be used 
alternatively or in addition. 

Administrative Object Keys 

In the preferred embodiment, an administrative object 
shared key may be used to decrypt the private header of an 
administrative object 870. In the case of administrative objects, a 
permissions record 808 may be present in the private header. In 
some cases, the permissions record 808 may be distributed as (or 
within) an administrative object that performs the function of 
providing a right to process the content of other administrative 
objects. The permissions record 808 preferably contains the keys 
for the private body, and the keys for the content that can be 
accessed would be budgets referenced in that permissions record 
808. The administrative object shared keys may incorporate time 
as a component, and may be replaced when expired. 

Stationary Object Keys 

A stationary object shared key may be used to decrypt a 
private header of stationary objects 850. As explained above, in 
some cases a permissions record 808 may be present in the 
private header of stationary objects. If present, the permissions 
record 808 may contain the keys for the private body but will not 
contain the keys for the content. These shared keys may 
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incorporate time as a component, and may be replaced when 
expired. 

Traveling Object Shared KeyB 

A traveling object shared key may be used to decrypt the 
private header of traveling objects 860. In the preferred 
embodiment, traveling objects contain permissions record 808 in 
their private headers. The permissions record 808 preferably 
contains the keys for the private body and the keys for the 
content that can be accessed as permitted by the permissions 
record 808. These shared keys may incorporate time as a 
component, and may be replaced when expired. 

Secure Database Keys 

PPE 650 preferably generates these secure database keys 
and never exposes them outside of the PPE. They are site- 
specific in the preferred embodiment, and may be "aged" as 
described above. As described above, each time an updated 
record is written to secure database 610, a new key may be used 
and kept in a key list within the PPE. Periodically (and when the 
internal list has no more room), the PPE 650 may generate a new 
key to encrypt new or old records. A group of keys may be used 
instead of a single key, depending on the size of the secure 
database 610. 
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Private Body Keys 

Private body keys are unique to an object 300, and are not 
dependent on key information shared between PPEs 650. They 
are preferably generated by the PPE 650 at the time the private 
body is encrypted, and may incorporate real-time as a component 
to "age" them. They are received in permissions records 808, and 
their usage may be controlled by budgets. 

Content Keys 

Content Keys are unique to an object 300, and are not 
dependent on key information shared between PPEs 650. They 
are preferably generated by the PPE 650 at the time the content 
is encrypted. They may incorporate time as a component to "age" 
them. They are received in permissions records 808, and their 
usage may be controlled by budgets. 

Authorization Shared Secrets 

Access to and use of information within a PPE 650 or 
within a secure database 610 may be controlled using 
authorization "shared secrets" rather than keys. Authorization 
shared secrets may be stored within the records they authorize 
(permissions records 808, budget records, etc.). The 
authorization shared secret may be formulated when the 
corresponding record is created. Authorization shared secrets 
can be generated by an authorizing PPE 650, and may be 
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replaced when record updates occur. Authorization shared 
secrets have some characteristics associated with "capabilities" 
used in capabilities based operating systems. Access tags 
(described below) are an important set of authorization shared 
secrets in the preferred embodiment. 

Backup Keys 

As described above, the secure database 610 backup 
consists of reading all secure database records and current audit 
"roll ups" stored in both PPE 650 and externally. Then, the 
backup process decrypts and re-encrypts this information using a 
new set of generated keys. These keys, the time of the backup, 
and other appropriate information to identify the backup, may be 
encrypted multiple times and stored with the previously 
encrypted secure database files and roll up data within the 
backup files. These files may then all be encrypted using a 
"backup key" that is generated and stored within PPE 650. This 
backup key 500 may be used by the PPE to recover a backup if 
necessary. The backup keys may also be securely encrypted (e.g., 
using a download authentication key and/or a VDE administrator 
public key) and stored within the backup itself to permit a VDE 
administrator to recover the backup in case of PPE 650 failure. 
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Cryptographic Sealing 

Sealing is used to protect the integrity of information when 
it may be subjected to modifications outside the control of the 
PPE 650, either accidentally or as an attack on the VDE security. 
Two specific applications may be the computation of check values 
for database records and the protection of data blocks that are 
swapped out of an SPE 500. 

There are two types of sealing: keyless sealing, also known 
as cryptographic hashing, and keyed sealing. Both employ a 
cryptographically strong hash function, such as MD5 or SHA. 
Such a function takes an input of arbitrary size and yields a 
fixed-size hash, or ''digest." The digest has the property that it is 
infeasible to compute two inputs that yield the same digest, and 
infeasible to compute one input that yields a specific digest value, 
where "infeasible" is with reference to a work factor based on the 
size of the digest value in bits. If, for example, a 256-bit hash 
function is to be called strong, it must require approximately on 
average 10 A 38 (2 A 128) trials before a duplicated or specified 
digest value is likely to be produced. 

Keyless seals may be employed as check values in database 
records (e.g., in PERC 808) and similar applications. A keyless 
seal may be computed based on the content of the body of the 
record, and the seal stored with the rest of the record. The 
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combination of seal and record may be encrypted to protect it in 
storage. If someone modifies the encrypted record without 
knowing the encryption key (either in the part representing the 
data or the part representing the seal), the decrypted content will 
be different, and the decrypted check value will not match the 
digest computed from the record's data. Even though the hash 
algorithm is known, it is not feasible to modify both the record's 
data and its seal to correspond because both are encrypted. 

Keyed seals may be employed as protection for data stored 
outside a protected environment without encryption, or as a 
validity proof between two protected environments. A keyed seal 
is computed similarly to a keyless seal, except that a secret initial 
value is logically prefixed to the data being sealed. The digest 
value thus depends both on the secret and the data, and it is 
infeasible to compute a new seal to correspond to modified data 
even though the data itself is visible to an attacker. A keyed seal 
may protect data in storage with a single secret value, or may 
protect data in transit between two environments that share a 
single secret value. 

The choice of keys or keyless seals depends on the nature 
of the data being protected and whether it is additionally 
protected by encryption. 
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Tagging 

Tagging is particularly useful for supporting the secure 
storage of important component assembly and related 
information on secondary storage memory 652. Integrated use of 
information "tagging" and encryption strategies allows use of 
inexpensive mass storage devices to securely store information 
that, in part enables, limits and/or records the configuration, 
management and operation of a VDE node and the use of VDE 
protected content. 

When encrypted or otherwise secured information is 
delivered into a user's secure VDE processing area (e.g., PPE 
650), a portion of this information can be used as a "tag" that is 
first decrypted or otherwise unsecured and then compared to an 
expected value to confirm that the information represents 
expected information. The tag thus can be used as a portion of a 
process confirming the identity and correctness of received, VDE 
protected, information. 

Three classes of tags that may be included in the control 
structures of the preferred embodiment: 

• access tags 

• validation tags 

• correlation tags. 
These tags have distinct purposes. 
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An access tag may be used as a "shared secret" between 
VDE protected elements and entities authorized to read and/or 
modify the tagged element(s). The access tag may be broken into 
separate fields to control different activities independently. If an 
access tag is used by an element such as a method core 1000', 
administrative events that affect such an element must include 
the access tag (or portion of the access tag) for the affected 
element(s) and assert that tag when an event is submitted for 
processing. If access tags are maintained securely (e.g., created 
inside a PPE 650 when the elements are created, and only 
released from PPE 650 in encrypted structures), and only 
distributed to authorized parties, modification of structures can 
be controlled more securely. Of course, control structures (e.g., 
PERCs 808) may further limit or qualify modifications or other 
actions expressed in administrative events. 

Correlation tags are used when one element references 
another element. For example, a creator might be required by a 
budget owner to obtain permission and establish a business 
relationship prior to referencing their budget within the creator's 
PERCs. After such relationship was formed, the budget owner 
might transmit one or more correlation tags to the creator as one 
aspect of allowing the creator to produce PERCs that reference 
the budget owner's budget. 
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Validation tags may be used to help detect record 
substitution attempts on the part of a tamperer. 

In some respects, these three classes of tags overlap in 
function. For example, a correlation tag mismatch may prevent 
some classes of modification attempts that would normally be 
prevented by an access tag mismatch before an access tag check 
is performed. The preferred embodiment may use this overlap in 
some cases to reduce overhead by, for example, using access tags 
in a role similar to validation tags as described above. 

In general, tagging procedures involve changing, within 
SPE 503, encryption key(s), securing techniques(s), and/or 
providing specific, stored tag(s). These procedures can be 
employed with secure database 610 information stored on said 
inexpensive mass storage 652 and used within a hardware SPU 
500 for authenticating, decrypting, or otherwise analyzing, using 
and making available VDE protected content and management 
database information. Normally, changing validation tags 
involves storing within a VDE node hardware (e.g., the PPE 650) 
one or more elements of information corresponding to the tagging 
changes. Storage of information outside of the hardware SPE's 
physically secure, trusted environment is a highly cost savings 
means of secure storage, and the security of important stored 
management database information is enhanced by this tagging of 
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information. Performing this tagging "change" frequently (for 
example, every time a given record is decrypted) prevents the 
substitution of "incorrect" information for "correct" information, 
since said substitution will not carry information which will 
match the tagging information stored within the hardware SPE 
during subsequent retrieval of the information. 

Another benefit of information tagging is the use of tags to 
help enforce and/or verify information and/or control mechanisms 
in force between two or more parties. If information is tagged by 
one party, and then passed to another party or parties, a tag can 
be used as an expected value associated with communications 
and/or transactions between the two parties regarding the tagged 
information. For example, if a tag is associated with a data 
element that is passed by Party A to Party B, Party B may 
require Party A to prove knowledge of the correct value of at least 
a portion of a tag before information related to, and/or part of, 
said data element is released by Party B to Party A, or vice versa. 
In another example, a tag may be used by Party A to verify that 
information sent by Party B is actually associated with, and/or 
part of, a tagged data element, or vice versa. 

Establishing A Secure, Authenticated, Communication Channel 

From time to time, two parties (e.g., PPEs A and B), will 
need to establish a communication channel that is known by both 
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parties to be secure from eavesdropping, secure from tampering, 
and to be in use solely by the two parties whose identifies are 
correctly known to each other. 

The following describes an example process for establishing 
such a channel and identifies how the requirements for security 
and authentication may be established and validated by the 
parties. The process is described in the abstract, in terms of the 
claims and belief each party must establish, and is not to be 
taken as a specification of any particular protocol. In particular, 
the individual sub-steps of each step are not required to be 
implemented using distinct operations; in practice, the 
establishment and validation of related proofs is often combined 
into a single operation. 

The sub-steps need not be performed in the order detailed 
below, except to the extent that the validity of a claim cannot be 
proven before the claim is made by the other party. The steps 
may involve additional communications between the two parties 
than are implied by the enumerated sub-steps, as the 
"transmission" of information may itself be broken into sub-steps. 
Also, it is not necessary to protect the claims or the proofs from 
disclosure or modification during transmission. Knowledge of the 
claims (including the specific communication proposals and 
acknowledgements thereof) is not considered protected 
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information. Any modification of the proofs will cause the proofs 
to become invalid and will cause the process to fail. 

Standard public-key or secret-key cryptographic 
techniques can be used to implement this process (e.g., X.509, 
Authenticated Diflfie-Hellman, Kerberos). The preferred 
embodiment uses the three-way X.509 public key protocol steps. 

The following may be the first two steps in the example 
process: 

A. (precursor step): Establish means of creating 
validatable claims by A 

B. (precursor step): Establish means of creating 
validatable claims by B 

These two steps ensure that each party has a means of 
making cl aim s that can be validated by the other party, for 
instance, by using a public key signature scheme in which both 
parties maintain a private key and make available a public key 
that itself is authenticated by the digital signature of a 
certification authority. 

The next steps may be: 

A (prppQsal stqp): 

1. Determine B's identity 
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3. 



2. 



Acquire means of validating claims made by B 
Create a unique identity for this specific proposed 



communication 



4. 



Create a communication proposal identifying the 



parties and the specific communication 

5. Create validatable proof of A's identity and the 
origin of the communication proposal 

6. Deliver communication proposal and associated 
proof to B. 

These steps establish the identity of the correspondent 
party B and proposes a communication. Because establishment 
of the communication will require validation of claims made by B, 
a means must be provided for A to validate such claims. Because 
the establishment of the communication must be unique to a 
specific requirement by A for communication, this communication 
proposal and all associated traffic must be unambiguously 
distinguishable from all other such traffic. Because B must 
validate the proposal as a legitimate proposal from A, a proof 
must be provided that the proposal is valid. 
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The next steps may be as follows: 
B (acknowledgement step) : 

1. Extract A's identity from the communication 
proposal 

2. Acquire means of validating claims made by A 

3. Validate A's claim of identity and communication 
proposal origin 

4. Determine the unique identification of the 
communication proposal 

5. Determine that the communication proposal does not 
duplicate an earlier proposal 

6. Create an acknowledgement identifying the specific 
communication proposal 

7. Create validatable proof of B's identity and the 
origin of the acknowledgement 

8. Deliver the acknowledgement and associated proof to 
A. 

These steps establish that party B has received A's 
communication proposal and is prepared to act on it. Because B 
must validate the proposal, B must first determine its origin and 
validate its authenticity. B must ensure that its response is 
associated with a specific proposal, and that the proposal is not a 
replay. If B accepts the proposal, it must prove both B's own 
identity and that B has received a specific proposal. 
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The next steps may be: 
A (establishment step): 

1. Validate B's claim acknowledgement of A's specific 
proposal 

2. Extract the identity of the specific communication 
proposal from the acknowledgement 

3. Determine that the acknowledgement is associated 
with an outstanding communication proposal 

4. Create unique session key to be used for the 
proposed communication 

5. Create proof of session key's creation by A 

6. Create proof of session key's association with the 
specific communication proposal 

7. Create proof of receipt of B's acknowledgement 

8. Protect the session key from disclosure in 
transmission 

9. Protect the session key from modification in 
transmission 

10. Deliver protected session key and all proofs to B. 

These steps allows A to specify a session key to be 
associated with all further traffic related to A's specific 
communication proposal. A must create the key, prove that A 
created it, and prove that it is associated with the specific 
proposed communication. In addition, A must prove that the 
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session key is generated in response to B's acknowledgement of 
the proposal. The session key must be protected from disclosure 
of modification to ensure that an attacker cannot substitute a 
different value. 

Transportability of VDE Installations Between PPEs 650 

In a preferred embodiment, VDE objects 300 and other 
secure information may if appropriate, be transported from one 
PPE 650 to another securely using the various keys outlined 
above. VDE 100 uses redistribution of VDE administrative 
information to exchange ownership of VDE object 300, and to 
allow the portability of objects between electronic appliances 600. 

The permissions record 808 of VDE objects 300 contains 
rights information that may be used to determine whether an 
object can be redistributed in whole, in part, or at all. If a VDE 
object 300 can be redistributed, then electronic appliance 600 
normally must have a "budget" and/or other permissioning that 
allows it to redistribute the object. For example, an electronic 
appliance 600 authorized to redistribute an object may create an 
administrative object containing a budget or rights less than or 
equal to the budget or rights that it owns. Some administrative 
objects may be sent to other PPEs 650. A PPE 650 that receives 
one of the administrative objects may have the ability to use at 
least a portion of the budgets, or rights, to related objects. 
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Transfer of ownership of a VDE object 300 is a special case 
in which all of the permissions and/or budgets for a VDE object 
are redistributed to a different PPE 650. Some VDE objects may 
require that all object-related information be delivered (e.g., it's 
possible to "sell" all rights to the object). However, some VDE 
objects 300 may prohibit such a transfer. In the case of 
ownership transfer, the original providers for a VDE object 300 
may need to be contacted by the new owner, informed of the 
transfer, and validated using an authorization shared secret that 
accompanies reauthorization, before transfer of ownership can be 
completed. 

When an electronic appliance 600 receives a component 
assembly, an encrypted part of the assembly may contain a value 
that is known only to the party or PPE 650 that supplied the 
assembly. This value may be saved with information that must 
eventually returned to the assembly supplier (e.g., audit, billing 
and related information). When a component supplier requests 
that information be reported, the value may be provided by the 
supplier so that the local electronic appliance 600 can check it 
against the originally supplied value to ensure that the request is 
legitimate. When a new component is received, the value may be 
checked against an old component to determine whether the new 
component is legitimate (e.g., the new value for use in the next 
report process may be included with the new component). 
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Integrity of VDE Security 

There are many ways in which a PPE 650 might be 
compromised. The goal of the security provided by VDE 100 is to 
reduce the possibility that the system will be compromised, and 
minimize the adverse effects if it is compromised. 

The basic cryptographic algorithm that are used to 
implement VDE 100 are assumed to be safe (cryptographically 
strong). These include the secret-key encryption of content, 
public-key signatures for integrity verification, public-key 
encryption for privacy between PPEs 650 or between a PPE and 
a VDE administrator, etc. Direct attack on these algorithms is 
assumed to be beyond the capabilities of an attacker. For 
domestic versions of VDE 100 some of this is probably a safe 
assumption since the basic building blocks for control information 
have sufficiently long keys and are sufficiently proven. 

The following risks of threat or attacks may be significant: 

• Unauthorized creation or modification of component 
assemblies (e.g., budgets) 

• Unauthorized bulk disclosure of content 

• Compromise of one or more keys 

• Software emulation of a hardware PPE 

• Substitution of older records in place of newer 
records 
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• Introduction of "rogue" (i.e., unauthentic) load 
modules 

• Replay attacks 

• Defeating "fingerprinting" 

• Unauthorized disclosure of individual content items 

• Redistribution of individual content items. 

A significant potential security breach would occur if one or 
more encryption keys are compromised. As discussed above, 
however, the encryption keys used by VDE 100 are sufficiently 
varied and compartmentalized so that compromising one key 
would have only limited value to an attacker in most cases. For 
example, if a certification private key is exposed, an attacker 
could pass the challenge/response protocol as discussed above but 
would then confront the next level of security that would entail 
cracking either the initialization challenge/response or the 
external communication keys. If the initialization 
challenge/response security is also defeated, the initialization 
code and various initialization keys would also be exposed. 
However, it would still be necessary to understand the code and 
data to find the shared VDE keys and to duplicate the key- 
generation ("convolution") algorithms. In addition, correct real 
time clock values must be maintained by the spoof. If the 
attacker is able to accomplish all of this successfully, then all 
secure communications to the bogus PPE would be compromised. 
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An object would be compromised if communications related to the 
permissions record 808 of that object are sent to the bogus PPE. 

Knowledge of the PPE download authorization key and the 
algorithms that are used to derive the key that encrypts the keys 
for backup of secured database 610 would compromise the entire 
secured database at a specific electronic appliance 600. However, 
in order to use this information to compromise content of VDE 
objects 300, an understanding of appropriate VDE internals 
would also be required. In a preferred embodiment, the private 
body keys and content keys stored in a secured database 610 are 
"aged" by including a time component. Time is convoluted with 
the stored values to derive the "true keys" needed to decrypt 
content. If this process is also compromised, then object content 
or methods would be revealed. Since a backup of secured 
database 610 is not ever restored to a PPE 650 in the preferred 
embodiment without the intervention of an authorized VDE 
administrator, a "bogus" PPE would have to be used to make use 
of this information. 

External communication shared keys are used in the 
preferred embodiment in conjunction with a key convolution 
algorithm based on site ID and time. If compromised, all of the 
steps necessary to allow communications with PPEs 650 must 
also be known to take advantage of this knowledge. In addition, 
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at least one of the administrative object shared keys must be 
compromised to gain access to a decrypted permissions record 
808. 

Compromising an administrative object shared key has no 
value unless the "cracker" also has knowledge of external 
communication keys. All administrative objects are encrypted by 
unique keys exchanged using the shared external 
communications keys, site ID and time. Knowledge of PPE 650 
internal details would be necessary to further decrypt the content 
of administrative objects. 

The private header of a stationary object (or any other 
stationary object that uses the same shared key) if compromised, 
may provide the attacker with access to content until the shared 
key "ages" enough to no longer decrypt the private header. 
Neither the private body nor the content of the object is exposed 
unless a permissions record 808 for that object is also 
compromised. The private headers of these objects may remain 
compromised until the key "ages" enough to no longer decrypt the 
private header. 

Secure database encryption keys in the preferred 
embodiment are frequently changing and are also site specific. 
The consequences of compromising a secured database 610 file or 
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a record depends on the information that has been compromised. 
For example, permissions record 808 contain keys for the public 
body and content of a VDE object 300. If a permissions record 
808 is compromised, the aspects of that object protected by the 
keys provided by the permissions record are also 
compromised — if the algorithm that generates the "true keys" is 
also known. If a private body key becomes known, the private 
body of the object is compromised until the key "ages" and 
expires. If the "aging" process for that key is also compromised, 
the breach is permanent. Since the private body may contain 
methods that are shared by a number of different objects, these 
methods may also become compromised. When the breach is 
detected, all administrative objects that provide budgets and 
permissions record should update the compromised methods. 
Methods stored in secure database 610 are only replaced by more 
recent versions, so the compromised version becomes unusable 
after the update is completed. 

If a content key becomes compromised, the portion of the 
content encrypted with the key is also compromised until the key 
"ages" and expires. If the "aging" process for that key also 
becomes compromised, then the breach becomes permanent. If 
multiple levels of encryption are used, or portions of the content 
are encrypted with different keys, learning a single key would be 
insufficient to release some or all of the content. 
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If an authorization shared secret (e.g., an access tag) 
becomes known, the record containing the secret may be modified 
by an authorized means if the "cracker" knows how to properly 
use the secret. Generally speaking, the external communications 
keys, the administrative object keys and the management file 
keys must also be "cracked" before a shared secret is useful. Of 
course, any detailed knowledge of the protocols would also be 
required to make use of this information. 

In the preferred embodiment, PPE 650 may detect whether 
or not it has become compromised. For example, by comparing 
information stored in an SPE 503 (e.g., summary service 
information) with information stored in secure database 610 
and/or transmitted to a VDE participant (e.g., a VDE 
clearinghouse), discrepancies may become evident. If PPE 650 
(or a VDE administrator watching its activities or communicating 
with it) detects that it has been compromised, it may be updated 
with an initialization to use new code, keys and new 
encryption/decryption algorithms. This would limit exposure to 
VDE objects 300 that existed at the time the encryption scheme 
was broken. It is possible to require the PPE 650 to cease 
functioning after a certain period of time unless new code and 
key downloads occur. It is also possible to have VDE 
administrators force updates to occur. It is also likely that the 
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desire to acquire a new VDE object 300 will provide an incentive 
for users to update their PPEs 650 at regular time intervals. 

Finally, the end-to-end nature of VDE applications, in 
which content 108 flows in one direction, generating reports and 
bills 118 in the other, makes it possible to perform "back-end" 
consistency checks. Such checks, performed in clearinghouses 
116, can detect patterns of use that may or do indicate fraud (e.g., 
excessive acquisition of protected content without any 
corresponding payment, usage records without corresponding 
billing records). The fine grain of usage reporting and the ready 
availability of usage records and reports in electronic form 
enables sophisticated fraud detection mechanisms to be built so 
that fraud-related costs can be kept to an acceptable level. 

PPE Initialization 

Each PPE 650 needs to be initialized before it can be used. 
Initialization may occur at the manufacturer site, after the PPE 
650 has been placed out in the field, or both. The manufacturing 
process for PPE 650 typically involves embedding within the PPE 
sufficient software that will allow the device to be more 
completely initialized at a later time. This manufacturing 
process may include, for example, testing the bootstrap loader 
and challenge-response software permanently stored within PPE 
650, and loading the PPE's unique ID. These steps provide a 
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basic VDE-capable PPE 650 that may be further initialized (e.g., 
after it has been installed within an electronic appliance 600 and 
placed in the field). In some cases, the manufacturing and 
farther initialization processes may be combined to produce 
"VDE ready" PPEs 650. This description elaborates on the 
summary presented above with respect to Figures 64 and 65. 

Figure 68 shows an example of steps that may be 
performed in accordance with one preferred embodiment to 
initialize a PPE 650. Some of the steps shown in this flowchart 
may be performed at the manufacturing site, and some may be 
performed remotely through contact between a VDE 
administrator and the PPE 650. Alternatively, all of the steps 
shown in the diagram may be performed at the manufacturing 
site, or all of the steps shown may be performed through remote 
communications between the PPE 500 and a VDE administrator. 

If the initialization process 1370 is being performed at the 
manufacturer, PPE 650 may first be attached to a testbed. The 
manufacturing testbed may first reset the PPE 650 (e.g., with a 
power on clear) (Block 1372). If this reset is being performed at 
the manufacturer, then the PPE 650 preferably executes a 
special testbed bootstrap code that completely tests the PPE 
operation from a software standpoint and fails if something is 
wrong with the PPE. A secure communications exchange may 
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then be established between the manufacturing testbed and the 
PPE 650 using an initial challenge-response interaction (Block 
1374) that is preferably provided as part of the testbed bootstrap 
process. Once this secure communications has been established, 
the PPE 650 may report the results of the bootstrap tests it has 
performed to the manufacturing testbed. Ass umin g the PPE 650 
has tested successfully, the manufacturing testbed may download 
new code into the PPE 650 to update its internal bootstrap code 
(Block 1376) so that it does not go through the testbed bootstrap 
process upon subsequent resets (Block 1376). The manufacturing 
testbed may then load new firmware into the PPE internal non- 
volatile memory in order to provide additional standard and/or 
customized capabilities (Block 1378). For example, the 
manufacturing testbed may preload PPE 650 with the load 
modules appropriate for the particular manufacturing lot. This 
step permits the PPE 500 to be customized at the factory for 
specific applications. 

The manufacturing testbed may next load a unique device 
ID into PPE 650 (Block 1380). PPE 650 now carries a unique ID 
that can be used for further interactions. 

Blocks 1372-1380R typically are, in the preferred 
embodiment, performed at the manufacturing site. Blocks 1374 
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and 1382-1388 may be performed either at the manufacturing 
site, after the PPE 650 has been deployed, or both. 

To further initialize PPE 650, once a secure 
communications has been established between the PPE and the 
manufacturing testbed or a VDE administrator (Block 1374), any 
required keys, tags or certificates are loaded into PPE 650 (Block 
1382). For example, the manufacturing test bed may load its 
information into PPE 650 so the PPE may be initialized at a later 
time. Some of these values may be generated internally within 
PPE 650. The manufacturing testbed or VDE administrator may 
then initialize the PPE real time clock 528 to the current real 
time value (Block 1384). This provides a time and date reference 
for the PPE 650. The manufacturing testbed or the VDE 
administrator may next initialize the summary values 
maintained internally to the PPE 500 (Block 1386). If the PPE 
650 is already installed as part of an electronic appliance 600, the 
PPE may at this point initialize its secure database 610 (Block 
1388). 

Figure 69 shows an example of program control steps 
performed by PPE 650 as part of a firmware download process 
(See Figure 68, Block 1378). The PPE download process is used 
to load externally provided firmware and/or data elements into 
the PPE. Firmware loads may take two forms: permanent loads 
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for software that remains resident in the PPE 650; and transient 
loads for software that is being loaded for execution. A related 
process for storing into the secure database 610 is perfonned for 
elements that have been sent to a VDE electronic appliance 600. 

PPE 650 automatically performs several checks to ensure 
that firmware being downloaded into the PPE has not been 
tampered with, replaced, or substituted before it was loaded. The 
download routine 1390 shown in the figure illustrates an 
example of such checks. Once the PPE 650 has received a new 
firmware item (Block 1392), it may check the item to ensure that 
it decrypts properly using the predetermined download or 
administrative object key (depending on the source of the 
element) (decision Block 1394). If the firmware decrypts properly 
Cyes" exits to decision Block 1394), the firmware as check valve 
may be calculated "and compared against the check valve stored 
under the encryption wrapper of the firmware (decision Block 
1396^. If the two check summed values compare favorably ("yes" 
exit to decision Block 1396), then the PPE 650 may compare the 
public and private header identification tags associated with the 
firmware to ensure that the proper firmware was provided and 
had not been substituted (step not shown in the figure). 
Assuming this test also passes, the PPE 500 may calculate the 
digital signatures of the firmware (assuming digital signatures 
are supported by the PPE 650 and the firmware is "signed") and 
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may check the calculated signature to ensure that it compares 
favorably to the digital signatures under the firmware encryption 
wrapper (Blocks 1398, 1400). If any of these tests fail, then the 
download will be aborted ("fail" termination 1401). 

Assuming all of the tests described above pass, then PPE 
650 determines whether the firmware is to be stored within the 
PPE (e.g., an internal non-volatile memory), or whether it is to be 
stored in the secure database 610 (decision Block 1402). If the 
firmware is to be stored within the PPE ("yes" exit to decision 
Block 1402), then the PPE 500 may simply store the information 
internally (Block 1404). If the firmware is to be stored within the 
secure database 610 ("no" exit to decision Block 1402), then the 
firmware may be tagged with a unique PPE-specific tag designed 
to prevent record substitution (Block 1406), and the firmware 
may then be encrypted using the appropriate secure database 
key and released to the secure database 610 (Block 1408). 

Networking SPUs 500 and/or VDE Electronic Appliances 600 

In the context of many computers interconnected by a local 
or wide area network, it would be possible for one or a few of 
them to be VDE electronic appliances 600. For example, a VDE- 
capable server might include one or more SPUs 500. This 
centralized VDE server could provide all VDE services required 
within the network or it can share VDE service with VDE server 
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nodes; that is, it can perform a few, some, or most VDE service 
activities. For example, a user's non-VDE computer could issue a 
request over the network for VDE-protected content. In response 
to the request, the VDE server could comply by accessing the 
appropriate VDE object 300, releasing the requested content and 
delivering the content over the network 672 to the requesting 
user. Such an arrangement would allow VDE capabilities to be 
easily integrated into existing networks without requiring 
modification or replacement of the various computers and other 
devices connected to the networks. 

For example, a VDE server having one or more protected 
processing environments 650 could communicate over a network 
with workstations that do not have a protected processing 
environment. The VDE server could perform all secure VDE 
processing, and release resulting content and other information 
to the workstations on the network. This arrangement would 
require no hardware or software modification to the 
workstations. 

However, some applications may require greater security, 
flexibility and/or performance that may be obtained by providing 
multiple VDE electronic appliances 600 connected to the same 
network 672. Because commonly-used local area networks 
constitute an insecure channel that may be subject to tampering 
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and/or eavesdropping, it is desirable in most secure applications 
to protect the information communicated across the network. It 
would be possible to use conventional network security 
techniques to protect VDE-released content or other VDE 
information communicated across a network 672 between a VDE 
electronic appliance 600 and a non-VDE electronic appliance. 
However, advantages are obtained by providing multiple 
networked VDE electronic appliances 600 within the same 
system. 

As discussed above in connection with Figure 8, multiple 
VDE electronic appliances 600 may communicate with one 
another over a network 672 or other communications path. Such 
networking of VDE electronic appliances 600 can provide 
advantages. Advantages include, for example, the possibility of 
centralizing VDE-resources, storing and/or archiving metering 
information on a server VDE and delivering information and 
services efficiently across the network 672 to multiple electronic 
appliances 600. 

For example, in a local area network topology, a "VDE 
server" electronic appliance 600 could store VDE-protected 
information and make it available to one or more additional 
electronic appliances 600 or computers that may co mm unicate 
with the server over network 672. As one example, an object 
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repository 728 storing VDE objects could be maintained at the 
centralized server, and each of many networked electronic 
appliance 600 users could access the centralized object repository 
over the network 672 as needed. When a user needs to access a 
particular VDE object 300, her electronic appliance 600 could 
issue a request over network 672 to obtain a copy of the object. 
The "VDE server" could deliver all or a portion of the requested 
object 300 in response to the request. Providing such a 
centralized object repository 728 would have the advantage of 
minimizing mass storage requirements local to each electronic 
appliance 600 connected to the network 672, eliminate redundant 
copies of the same information, ease information management 
burdens, provide additional physical and/or other security for 
particularly important VDE processes and/or information 
occurring at the server, where providing such security at VDE 
nodes may be commercially impractical for certain business 
models, etc. 

It may also be desirable to centralize secure database 610 
in a local area network topology. For example, in the context of a 
local area network, a secure database 610 server could be 
provided at a centralized location. Each of several electronic 
appliances 600 connected to a local area network 672 could issue 
requests for secure database 610 records over the network, and 
receive those records via the network. The records could be 
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provided over the network in encrypted form. "Keys" needed to 
decrypt the records could be shared by transmitting them across 
the network in secure communication exchanges. Centralizing 
secure database 610 in a network 672 has potential advantages 
of minimizing or eliminating secondary storage and/or other 
memory requirements for each of the networked electronic 
appliances 600, avoiding redundant information storage, allowing 
centralized backup services to be provided, easing information 
management burdens, etc. 

One way to inexpensively and conveniently deploy multiple 
instances of VDE electronic appliances 600 across a network 
would be to provide network workstations with software defining 
an HPE 655. This arrangement requires no hardware 
modification of the workstations; an HPE 655 can be defined 
using software only. An SPE(s) 503 and/or HPE(s) 655 could also 
be provided within a VDE server. This arrangement has the 
advantage of allowing distributed VDE network processing 
without requiring workstations to be customized or modified 
(except for loading a new program(s) into them). VDE functions 
requiring high levels of security may be restricted to an SPU- 
based VDE server. "Secure'' HPE-based workstations could 
perform VDE functions requiring less security, and could also 
coordinate their activities with the VDE server. 
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Thus, it may be advantageous to provide multiple VDE 
electronic appliances 600 within the same network. It may also 
be advantageous to provide multiple VDE electronic appliances 
600 within the same workstation or other electronic appliance 
600. For example, an electronic appliance 600 may include 
multiple electronic appliances 600 each of which have a SPU 500 
and are capable of performing VDE functions. 

For example, one or more VDE electronic appliances 600 
can be used as input/output device(s) of a computer system. This 
may eliminate the need to decrypt information in one device and 
then move it in unencrypted form across some bus or other 
unsecured channel to another device such as a peripheral. If the 
peripheral device itself is a VDE electronic appliance 600 having 
a SPU 500, VDE-protected information may be securely sent to 
the peripheral across the insecure channel for processing (e.g., 
decryption) at the peripheral device. Giving the peripheral 
device the capability of handling VDE-protected information 
directly also increases flexibility. For example, the VDE 
electronic appliance 600 peripheral device may control VDE 
object 300 usage. It may, for example, meter the usage or other 
parameters associated with the information it processes, and it 
may gather audit trials and other information specific to the 
processing it performs in order to provide greater information 
gathering about VDE object usage. Providing multiple 
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cooperating VDE electronic appliances 600 may also increase 
performance by eliminating the need to move encrypted 
information to a VDE electronic appliance 600 and then move it 
again in unencrypted form to a non-VDE device. The VDE- 
protected information can be moved directly to its destination 
device which, if VDE-capable, may directly process it without 
requiring involvement by some other VDE electronic appliance 
600. 



Figure 70 shows an example of an arrangement 2630 
comprising multiple VDE electronic appliances 600(1), 600(2), 
600(3), . . . , 600(N). VDE electronic appliances 600(1) . . . 600(N) 
may communicate with one another over a communications path 
2631 (e.g., the system bus of a work station, a telephone or other 
wire, a cable, a backplane, a network 672, or any other 
communications mechanism). Each of the electronic appliances 
600 shown in the figure may have the same general architecture 
shown in Figure 8, i.e., they may each include a CPU (or 
microcontroller) 654, SPU 500, RAM 656, ROM 658, and system 
bus 653. Each of the electronic appliances 600 shown in the 
figure may have an interface/controller 2632 (which may be 
considered to be a particular kind of I/O controller 660 and/or 
communications controller 666 shown in Figure 8). This 
interface/controller 2632 provides an interface between the 
electronic appliance system bus 653 and an appropriate electrical 
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connector 2634. Electrical connectors 2634 of each of the 
respective electronic appliances 600(1), . . . 600(N) provide a 
connection to a common network 672 or other communication 
paths. 

Although each of electronic appliances 600 shown in the 
figure may have a generally similar architecture, they may 
perform different specialized tasks. For example, electronic 
appliance 600(1) might comprise a central processing section of a 
workstation responsible for managing the overall operation of the 
workstation and providing computation resources. Electronic 
appliance 600(2) might be a mass storage device 620 for the same 
workstation, and could provide a storage mechanism 2636 that 
might, for example, read information from and write information 
to a secondary storage device 652. Electronic appliance 600(3) 
might be a display device 614 responsible for performing display 
tasks, and could provide a displaying mechanism 2638 such as a 
graphics controller and associated video or other display. 
Electronic appliance 600(N) might be a printer 622 that performs 
printing related tasks and could include, for example, a print 
mechanism 2640. 

Each of electronic appliances 600(1), . . . 600(N) could 
comprise a different module of the same workstation device all 
contained within a common housing, or the different electronic 
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appliances could be located within different system components. 
For example, electronic appliance 600(2) could be disposed within 
a disk controller unit, electronic appliance 600(3) could be 
disposed within a display device 614 housing, and the electronic 
appliance 600CN) could be disposed within the housing of a 
printer 622. Referring back to Figure 7, scanner 626, modem 
618, telecommunication means 624, keyboard 612 and/or voice 
recognition box 613 could each comprise a VDE electronic 
appliance 600 having its own SPU 500. Additional examples 
include RF or otherwise wireless interface controller, a serial 
interface controller, LAN controllers, MPEG (video) controllers, 
etc. 

Because electronic appliances 600(1) . . . 600(N) are each 
VDE-capable, they each have the ability to perform encryption 
and/or decryption of VDE-protected information. This means 
that information communicated across network 672 or other 
communications path 2631 connecting the electronic appliances 
can be VDE-protected (e.g., it may be packaged in the form of 
VDE administrative and/or content objects and encrypted as 
discussed above). One of the consequences of this arrangement is 
that an eavesdropper who taps into communications path 2631 
will not be able obtain information except in VDE-protected form. 
For example, information generated by electronic appliance 600 
(1) to be printed could be packaged in a VDE content object 300 
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and transmitted over path 2631 to electronic appliance 600 (N) 
for printing. An attacker would gain little benefit from 
intercepting this information since it is transmitted in protected 
form; she would have to compromise electronic appliance 600(1) 
or 600(N) (or the SPU 500(1), 500(N)) in order to access this 
information in unprotected form. 

Another advantage provided by the arrangement shown in 
the diagram is that each of electronic appliances 600(1), . . . 
600(N) may perform their own metering, control and/or other 
VDE-related functions. For example, electronic appliance 600(N) 
may meter and/or perform any other VDE control functions 
related to the information to be printed, electronic appliance 
600(3) may meter and/or perform any other VDE control 
functions related to the information to be displayed, electronic 
appliance 600(2) may meter and/or perform any other VDE 
control functions related to the information to be stored and/or 
retrieved from mass storage 620, and electronic appliance 600(1) 
may meter and/or perform any other VDE control functions 
related to the information it processes. 

In one specific arrangement, each of electronic appliances 
600(1), . . . 600(N) would receive a command that indicates that 
the information received by or sent to the electronic appliance is 
to use its SPU 500 to process the information to follow. For 
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example, electronic appliance 600(N) might receive a command 
that indicates that information it is about to receive for printing 
is in VDE-protected form (or the information that is sent to it 
may itself indicate this). Upon receiving this command or other 
information, electronic appliance 600(N) may decrypt the 
received information using SPU 500, and might also meter the 
information the SPU provides to the print mechanism 2644 for 
printing. An additional command might be sent to electronic 
appliance 600(N) to disable the decryption process or 600(N)'s 
VDE secure subsystem may determine that the information 
should not be decrypted and/or printed. Additional commands, 
for example, may exist to load encryption/decryption keys, load 
"limits," establish "fingerprinting" requirements, and read 
metered usage. These additional commands may be sent in 
encrypted or unencrypted form as appropriate. 

Suppose, for example, that electronic appliance 600(1) 
produces information it wishes to have printed by a VDE-capable 
printer 622. SPU 500(1) could establish a secure communications 
across path 2631 with SPU 500(N) to provide a command 
instructing SPU 500(N) to decrypt the next block of data and 
store it as a decryption key and a limit. SPU 500(1) might then 
send a further command to SPU 500(N) to use the decryption key 
and associated limit to process any following encrypted print 
stream (or this command could be sent by CPU 654(1) to 
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microcontroller 654(N)). Electronic appliance 600(1) could then 
begin sending encrypted information on path 672 for decryption 
and printing by printer 622. Upon receipt of each new block of 
information by printer 622, SPU 500(N) might first check to 
ensure that the limit is greater than zero. SPU 500(N) could 
then increment a usage meter value it maintains, and decrement 
the limit value. If the limit value is non-zero, SPU 500(N) could 
decrypt the information it has received and provide it to print 
mechanism 2640 for printing. If the limit is zero, then SPU 
500(N) would not send the received information to the print 
mechanism 2640, nor would it decrypt it. Upon receipt of a 
command to stop, printer 622 could revert to a ''non-secure" mode 
in which it would print everything received by it across path 2631 
without permitting VDE processing. 

The SPU 500(N) associated with printer 622 need not 
necessarily be disposed within the housing of the printer, but 
could instead be placed within an I/O controller 660 for example 
(see Figure 8). This would allow at least some of the advantages 
similar to the ones discussed above to be provided without 
requiring a special VDE-capable printer 622. Alternatively, a 
SPU 500(N) could be provided both within printer 622 and within 
I/O controller 660 communicating with the printer to provide 
advantages in terms of coordinating I/O control and relieving 
processing burdens from the SPU 500 associated with the central 
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processing electronic appliance 600(1). When multiple VDE 
instances occur within an electronic appliance, one or more VDE 
secure subsystems may be "central" subsystems, that is 
"secondary" VDE instances may pass encrypted usage related 
information to one or more central secure subsystems so as to 
allow said central subsystem to directly control storage of said 
usage related information. Certain control information may also 
be centrally stored by a central subsystem and all or a portion of 
such information may be securely provided to the secondary 
secure subsystem upon its secure VDE request. 

Portable Electronic Appliance 

Electronic appliance 600 provided by the present invention 
may be portable. Figure 71 shows one example of a portable 
electronic appliance 2600. Portable appliance 2600 may include 
a portable housing 2602 that may be about the size of a credit 
card in one example. Housing 2602 may connect to the outside 
world through, for example, an electrical connector 2604 having 
one or more electrical contact pins (not shown). Connector 2604 
may electrically connect an external bus interface 2606 internal 
to housing 2602 to a mating connector 2604a of a host system 
2608. External bus interface 2606 may, for example, comprise a 
PCMCIA (or other standard) bus interface to allow portable 
appliance 2600 to interface with and communicate over a bus 
2607 of host system 2608. Host 2608 may, for example, be almost 
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any device imaginable, such as a computer, a pay telephone, 
another VDE electronic appliance 600, a television, an arcade 
video game, or a washing machine, to name a few examples. 

Housing 2602 may be tamper resistant. (See discussion 
above relating to tamper resistance of SPU barrier 502.) 

Portable appliance 2600 in the preferred embodiment 
includes one or more SPUs 500 that may be disposed within 
housing 2602. SPU 500 may be connected to external bus 
interface 2606 by a bus 2610 internal to housing 2602. SPU 500 
communicates with host 2608 (through external bus interface 
2606) over this internal bus 2610. 

SPU 500 may be powered by a battery 2612 or other 
portable power supply that is preferably disposed within housing 
2602. Battery 2612 may be, for example, a miniature battery of 
the type found in watches or credit card sized calculators. 
Battery 2612 may be supplemented (or replaced) by solar cells, 
rechargeable batteries, capacitive storage cells, etc. 

A random access memory (RAM) 2614 is preferably 
provided within housing 2602. RAM 2614 may be connected to 
SPU 500 and not directly connected to bus 2610, so that the 
contents of RAM 2614 may be accessed only by the SPU and not 
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by host 2608 (except through and as permitted by the SPU). 
Looking at Figure 9 for a moment, RAM 2614 may be part of 
RAM 534 within the SPU 500, although it need not necessarily 
be contained within the same integrated circuit or other package 
that houses the rest of the SPU. 

Portable appliance 2600 RAM 534 may contain, for 
example, information which can be used to uniquely identify each 
instance of the portable appliance. This information may be 
employed (e.g. as at least a portion of key or password 
information) in authentication, verification, decryption, and/or 
encryption processes. 

Portable appliance 2600 may, in one embodiment, comprise 
means to perform substantially all of the functions of a VDE 
electronic appliance 600. Thus, for example, portable appliance 
2600 may include the means for storing and using permissions, 
methods, keys, programs, and/or other information, and can be 
capable of operating as a "stand alone" VDE node. 

In a further embodiment, portable appliance 2600 may 
perform preferred embodiment VDE functions once it has been 
coupled to an additional external electronic appliance 600. 
Certain information, such as database management 
permission(s), method(s), key(s), and/or other important 
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information (such as at least a portion of other VDE programs: 
administrative, user-interface, analysis, etc.) may be stored (for 
example as records) at an external VDE electronic appliance 600 
that may share information with portable appliance 2600. 

One possible "stand alone" configuration for 
tamper-resistant, portable appliance 2600 arrangements includes 
a tamper-resistant package (housing 2602) containing one or 
more processors (500, 2616) and/or other computing devices 
and/or other control logic, along with random-access-memory 
2614. Processors 500, 2616 may execute permissions and 
methods wholly (or at least in part) within the portable appliance 
2600. The portable appliance 2600 may have the ability to 
encrypt information before the information is communicated 
outside of the housing 2602 and/or decrypt received information 
when said received information is received from outside of the 
housing. This version would also possess the ability to store at 
least a portion of permission, method, and/or key information 
securely within said tamper resistant portable housing 2602 on 
non-volatile memory. 

Another version of portable appliance 2600 may obtain 
permissions and/or methods and/or keys from a local VDE 
electronic appliance 600 external to the portable appliance 2600 
to control, limit, or otherwise manage a user's use of a VDE 
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protected object. Such a portable appliance 600 may be contained 
within, received by, installed in, or directly connected to, another 
electronic appliance 2600. 

One example of a "minimal" configuration of portable 
appliance 2600 would include only SPU 500 and battery 2612 
within housing 2602 (the external bus interface 2606 and the 
RAM 2614 would in this case each be incorporated into the SPU 
block shown in the Figure). In other, enhanced examples of 
portable appliance 2600, any or all of the following optional 
components may also be included within housing 2602: 

one or more CPUs 2616 (with associated support 

components such as RAM-ROM 2617, I/O controllers 
(not shown), etc.); 

one or more display devices 2618; 

one or more keypads or other user input buttons/control 

information 2620; 
one or more removable/replaceable memory device(s) 2622; 

and 

one or more printing device(s) 2624. 

In such more enhanced versions, the display 2618, keypad 2620, 
memory device 2622 and printer 2624 may be connected to bus 
2610, or they might be connected to CPU 2616 through an I/O 
port/controller portion (not shown) of the CPU. Display 2618 may 
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be used to display information from SPU 500, CPU 2616 and/or 
host 2608. Keypad 2620 may be used to input information to 
SPU 500, CPU 2616 and/or host 2608. Printer 2624 may be used 
to print information from any/all of these sources. 
Removable/replaceable memory 2622 may comprise a memory 
cartridge or memory medium such as a bulk storage device, for 
providing additional long-term or short-term storage. Memory 
2622 may be easily removable from housing 2602 if desired. 

In one example embodiment, portable appliance 2600 may 
have the form factor of a "smart card" (although a "smart card" 
form factor may provide certain advantages, housing 2602 may 
have the same or different form factor as "conventional" smart 
cards). Alternatively, such a portable electronic appliance 2600 
may, for example, be packaged in a PCMCIA card configuration 
(or the like) which is currently becoming quite popular on 
personal computers and is predicted to become common for 
desk-top computing devices and Personal Digital Assistants. One 
advantageous form factor for the portable electronic appliance 
housing 2602 may be, for example, a Type 1, 2, or 3 PCMCIA 
card (or other derivations) having credit card or somewhat larger 
dimensions. Such a form factor is conveniently portable, and 
may be insertable into a wide array of computers and consumer 
appliances, as well as receptacles at commercial establishments 
such as retail establishments and banks, and at public 
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communications points, such as telephone or other 
telecommunication booths." 

Housing 2602 may be insertable into and removable from a 
port, slot or other receptacle provided by host 2608 so as to be 
physically (or otherwise operatively) connected to a computer or 
other electronic appliance. The portable appliance connector 
2604 may be configured to allow easy removability so that 
appliance 2600 may be moved to another computer or other 
electronic appliance at a different location for a physical 
connection or other operative connection with that other device. 

Portable electronic appliance 2600 may provide a valuable 
and relatively simple means for a user to move permissions and 
methods between their (compatible) various electronic appliances 
600, such as between a notebook computer, a desktop computer 
and an office computer. It could also be used, for example, to 
allow a consumer to visit a next door neighbor and allow that 
neighbor to watch a movie that the consumer had acquired a 
license to view, or perhaps to listen to an audio record on a large 
capacity optical disk that the consumer had licensed for 
unlimited plays. 

Portable electronic appliance 2600 may also serve as a 
"smart card" for financial and other transactions for users to 
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employ in a variety of other applications such as, for example, 
commercial applications. The portable electronic appliance 2600 
may, for example, carry permission and/or method information 
used to authorize (and possibly record) commercial processes and 
services. 

An advantage of using the preferred embodiment VDE 
portable appliance 2600 for financial transactions such as those 
typically performed by banks and credit card companies is that 
VDE allows financial clearinghouses (such as VISA, MasterCard, 
or American Express) to experience significant reductions in 
operating costs. The clearinghouse reduction in costs result from 
the fact that the local metering and budget management that 
occurs at the user site through the use of a VDE electronic 
appliance 600 such as portable appliance 2600 frees the 
clearinghouse from being involved in every transaction. In 
contrast to current requirements, clearinghouses will be able to 
perform their functions by periodically updating their records 
(such as once a month). Audit and/or budget "roll-ups" may occur 
during a connection initiated to communicate such audit and/or 
budget information and/or through a connection that can occur at 
periodic or relatively periodic intervals and/or during a credit 
updating, purchasing, or other portable appliance 2600 
transaction. 
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Clearinghouse VDE digital distribution transactions would 
require only occasional authorization and/or audit or other 
administrative "roll-ups" to the central service, rather than far 
more costly connections during each session. Since there would 
be no requirement for the maintenance of a credit card purchase 
"paper trail" (the authorization and then forwarding of the credit 
card slip), there could be substantial cost reductions for 
clearinghouses (and, potentially, lower costs to users) due to 
reduction in communication costs, facilities to handle concurrent 
processing of information, and paper handling aspects of 
transaction processing costs. This use of a portable appliance 
2600 would allow credit enforcement to exploit distributed 
processing employing the computing capability in each VDE 
electronic appliance 600. These credit cost and processing 
advantages may also apply to the use of non-smart card and 
non-portable VDE electronic appliance 600s. 

Since VDE 100 may be configured as a highly secure 
commercial environment, and since the authentication processes 
supported by VDE employ digital signature processes which 
provide a legal validation that should be equivalent to paper 
documentation and handwritten signatures, the need for portable 
appliance 2600 to maintain paper trails, even for more costly 
transactions, is eliminated. Since auditable billing and control 
mechanisms are built into VDE 100 and automated, they may 
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replace traditional electronic interfaces to VISA, Master Card, 
AMEX, and bank debit accounts for digitally distributed other 
products and services, and may save substantial operating costs 
for such clearinghouses. 

Portable appliance 2600 may, if desired, maintain for a 
consumer a portable electronic history. The portable history can 
be, for example, moved to an electronic "dock" or other receptacle, 
in or operatively connected to, a computer or other consumer host 
appliance 2608. Host appliance 2608 could be, for example, an 
electronic organizer that has control logic at least in part in the 
form of a microcomputer and that stores information in an 
organized manner, e.g., according to tax and/or other transaction 
categories (such as type of use or activity). By use of this 
arrangement, the consumer no longer has to maintain receipts or 
otherwise manually track transactions but nevertheless can 
maintain an electronic, highly secure audit trail of transactions 
and transaction descriptions. The transaction descriptions may, 
for example, securely include the user's digital signature, and 
optionally, the service or goods provider's digital signature. 

When a portable appliance 2600 is "docked" to a host 2608 
such as a personal computer or other electronic appliance (such 
as an electronic organizer), the portable appliance 2600 could 
communicate interim audit information to the host. In one 
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embodiment, this information could be read, directly or 
indirectly, into a computer or electronic organizer money and/or 
tax management program (for example, Quicken or Microsoft 
Money and/or Turbo Tax and/or Andrew Tobias' Managing Your 
Money). This automation of receipt management would be an 
enormous boon to consumers, since the management and 
maintenance of receipts is difficult and time-consuming, receipts 
are often lost or forgotten, and the detail from credit card billings 
is often wholly inadequate for billing and reimbursement 
purposes since credit card b illin gs normally don't provide 
sufficient data on the purchased items or significant transaction 
parameters. 

In one embodiment, the portable appliance 2600 could 
support secure (in this instance encrypted and/or authenticated) 
two-way communications with a retail terminal which may 
contain a VDE electronic appliance 600 or communicate with a 
retailer's or third party provider's VDE electronic appliance 600. 
During such a secure two-way communication between, for 
example, each participant's secure VDE subsystem, portable 
appliance 2600 VDE secure subsystem may provide 
authentication and appropriate credit or debit card information 
to the retail terminal VDE secure subsystem. During the same 
or different communication session, the terminal could similarly, 
securely communicate back to the portable appliance 2600 VDE 
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secure subsystem details as to the retail transaction (for example, 
what was purchased and price, the retail establishments digital 
signature, the retail terminal's identifier, tax related information, 
etc.). 

For example, a host 2608 receptacle for receiving and/or 
attaching to portable appliance 2600 could be incorporated into 
or operatively connected to, a retail or other commercial 
establishment terminal. The host terminal 2608 could be 
operated by either a commercial establishment employee or by 
the portable appliance 2600 holder. It could be used to, for 
example, input specific keyboard and/or voice input specific 
information such as who was taken to dinner, why something 
was purchased, or the category that the information should be 
attached to. Information could then be automatically "parsed" 
and routed into securely maintained (for example, encrypted) 
appropriate database management records within portable 
appliance 2600. Said "parsing" and routing would be securely 
controlled by VDE secure subsystem processes and could, for 
example, be based on category information entered in by the user 
and/or based on class of establishment and/or type (category) of 
expenditure information (or other use). Categorization can be 
provided by the retail establishment, for example, by securely 
communicating electronic category information as a portion, for 
example, of electronic receipt information or alternatively by 
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printing a hard copy receipt using printer 2624. This process of 
categorization may take place in the portable appliance 2600 or, 
alternatively, it could be performed by the retail establishment 
and periodically "rolled-up" and communicated to the portable 
appliance 2600 holder. 

Retail, clearinghouse, or other commercial organizations 
may maintain and use by securely communicating to appliance 
2600 one or more of generic classifications of transaction types 
(for example, as specified by government taxation rules) that can 
be used to automate the parsing of information into records 
and/or for database information "roll-ups" for; and/or in portable 
appliance 2600 or one or more associated VDE nodes. In such 
instances, host 2608 may comprise an auxiliary ter min al, for 
example, or it could comprise or be incorporated directly within a 
commercial establishments cash registers or other retail 
transactions devices. The auxiliary terminal could be menu 
and/or icon driven, and allow very easy user selection of 
categorization. It could also provide templates, based on 
transaction type, that could guide the user through specifying 
useful or required transaction specific information (for example, 
purpose for a business dinner and/or who attended the dinner). 
For example, a user might select a business icon, then select from 
travel, sales, meals, administration, or purchasing icons for 
example, and then might enter in very specific information 
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and/or a key word, or other code that might cause the 
downloading of a transaction's detail into the portable appliance 
2600. This information might also be stored by the commercial 
establishment, and might also be communicated to the 
appropriate government and/or business organizations for 
validation of the reported transactions (the high level of security 
of auditing and communications and authentication and 
validation of VDE should be sufficiently trusted so as not to 
require the maintenance of a parallel audit history, but parallel 
maintenance may be supported, and maintained at least for a 
limited period of time so as to provide backup information in the 
event of loss or "failure" of portable appliance 2600 and/or one or 
more appliance 2600 associated VDE installations employed by 
appliance 2600 for historical and/or status information record 
maintenance). For example, of a retail terminal maintained 
necessary transaction information concerning a transaction 
involving appliance 2600, it could communicate such information 
to a clearinghouse for archiving (and/or other action) or it could 
periodically, for example, at the end of a business day, securely 
communicate such information, for example, in the form of a VDE 
content container object, to a clearinghouse or clearinghouse 
agent. Such transaction history (and any required VDE related 
status information such as available credit) can be maintained 
and if necessary, employed to reconstruct the information in a 
portable appliance 2600 so as to allow a replacement appliance to 
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be provided to an appliance 2600 user or properly reset internal 
information in data wherein such replacement and/or resetting 
provides all necessary transaction and status information. 

In a retail establishment, the auxiliary terminal host 2608 
might take the form of a portable device presented to the user, for 
example at the end of a meal. The user might place his portable 
appliance 2600 into a smart card receptacle such as a PCMCIA 
slot, and then enter whatever additional information that might 
appropriately describe the transaction as well as satisfying 
whatever electronic appliance 600 identification procedure(s) 
required. The transaction, given the availability of sufficient 
credit, would be approved, and transaction related information 
would then be communicated back from the auxiliary terminal 
directly into the portable appliance 2600. This would be a highly 
convenient mode of credit usage and record management. 

The portable device auxiliary terminal might be "on-line," 
that is electronically communicating back to a commercial 
establishment and/or third party information collection point 
through the use of cellular, satellite, radio frequency, or other 
communications means. The auxiliary terminal might, after a 
check by a commercial party in response to receipt of certain 
identification information at the collection point, communicate 
back to the auxiliary terminal whether or not to accept the 
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portable appliance 2600 based on other information, such as a 
bad credit record or a stolen portable appliance 2600. Such a 
portable auxiliary terminal would also be very useful at other 
commercial establishments, for example at gasoline stations, 
rental car return areas, street and stadium vendors, bars, and 
other commercial establishments where efficiency would be 
optimized by allowing clerks and other personnel to consummate 
transactions at points other than traditional cash register 
locations. 

As mentioned above, portable appliance 2600 may 
communicate from time to time with other electronic appliances 
600 such as, for example, a VDE administrator. Communication 
during a portable appliance 2600 usage session may result from 
internally stored parameters dictating that the connection should 
take place during^that current session (or next or other session) 
of use of the portable appliance. The portable appliance 600 can 
carry information concerning a real-time date or window of time 
or duration of time that will, when appropriate, require the 
communication to take place (e.g., perhaps before the transaction 
or other process which has been contemplated by the user for 
that session or during it or immediately following it). Such a 
communication can be accomplished quickly, and could be a 
secure, VDE two-way communication during which information 
is communicated to a central information handler. Certain other 



684 



WO 96/27155 



PCT/US96/02303 



information may be communicated to the portable appliance 2600 
and/or the computer or other electronic appliance to which the 
portable appliance 2600 has been connected. Such 
communicated other information can enable or prevent a 
contemplated process from proceeding, and/or make the portable 
appliance 2600, at least in part, unusable or useable. 
Information communicated to the portable appliance 2600 could 
include one or more modifications to permissions and methods, 
such as a resetting or increasing of one or more budgets, adding 
or withdrawing certain permissions, etc. 

The permissions and/or methods (i.e., budgets) carried by 
the portable appliance 2600 may have been assigned to it in 
conjunction with an "encumbering" of another, stationary or 
other portable VDE electronic appliance 600. In one example, a 
portable appliance 2600 holder or other VDE electronic appliance 
600 and/or VDE electronic appliance 600 user could act as 
"guarantor" of the financial aspects of a transaction performed by 
another party. The portable appliance 2600 of the holder would 
record an "encumbrance," which may be, during a secure 
communication with a clearinghouse, be recorded and 
maintained by the clearinghouse and/or some other financial 
services party until all or a portion of debt responsibilities of the 
other party were paid or otherwise satisfied. Alternatively or in 
addition, the encumbrance may also be maintained within the 
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portable appliance 2600, representing the contingent obligation 
of the guarantor. The encumbrance may be, by some formula, 
included in a determination of the credit available to the 
guarantor. The credit transfer, acceptance, and/or record 
management, and related processes, may be securely maintained 
by the security features provided by aspects of the present 
invention. Portable appliance 600 may be the sole location for 
said permissions and/or methods for one or more VDE objects 
300, or it may carry budgets for said objects that are independent 
of budgets for said objects that are found on another, 
non-portable VDE electronic appliance 600. This may allow 
budgets, for example, to be portable, without requiring 
"encumbering" and budget reconciliation. 

Portable VDE electronic appliance 2600 may carry (as may 
other VDE electronic appliance 600s described) information 
describing credit history details, summary of authorizations, and 
usage history information (e.g., audit of some degree of 
transaction history or related summary information such as the 
use of a certain type/class of information) that allows re-use of 
certain VDE protected information at no cost or at a reduced cost. 
Such usage or cost of usage may be contingent, at least in part, 
on previous use of one or more objects or class of objects or 
amount of use, etc., of VDE protected information. 
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Portable appliance 2600 may also carry certain information 
which may be used, at least in part, for identification purposes. 
This information may be employed in a certain order (e.g. a 
pattern such as, for example, based on a pseudo-random 
algorithm) to verify the identity of the carrier of the portable 
appliance 2600. Such information may include, for example, 
one's own or a wife's and/or other relatives maiden names, social 
security number or numbers of one's own and/or others, birth 
dates, birth hospital(s), and other identifying information. It may 
also or alternatively provide or include one or more passwords or 
other information used to identify or otherwise 
verify/authenticate an individual's identity, such as voice print 
and retinal scan information. For example, a portable appliance 
2600 can be used as a smart card that carries various 
permissions and/or method information for authorizations and 
budgets. This information can be stored securely within portable 
appliance 2600 in a secure database 610 arrangement. When a 
user attempts to purchase or license an electronic product or 
otherwise use the "smart card" to authorize a process, portable 
appliance 2600 may query the user for identification information 
or may initiate an identification process employing scanned or 
otherwise entered information (such as user fingerprint, retinal 
or voice analysis or other techniques that may, for example, 
employ mapping and/or matching of provided characteristics to 
information securely stored within the portable appliance 2600). 
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The portable appliance 2600 may employ different queries at 
different times (and/or may present a plurality of queries or 
requests for scanning or otherwise entering identifying 
information) so as to prevent an individual who has come into 
possession of appropriate information for one or more of the 
"tests" of identity from being able to successfully employ the 
portable appliance 2600. 

A portable appliance 600 could also have the ability to 
transfer electronic currency or credit to another portable 
appliance 2600 or to another individual's account, for example, 
using secure VDE communication of relevant content between 
secure VDE subsystems. Such transfer may be accomplished, for 
example, by telecommunication to, or presentation at, a bank 
which can transfer credit and/or currency to the other account. 
The transfer could also occur by using two cards at the same 
portable appliance 2600 docking station. For example, a credit 
transaction workstation could include dual PCMCIA slots and 
appropriate credit and/or currency transfer application software 
which allows securely debiting one portable appliance 2600 and 
"crediting" another portable appliance (i.e., debiting from one 
appliance can occur upon issuing a corresponding credit and/or 
currency to the other appliance). One portable appliance 600, for 
example, could provide an authenticated credit to another user. 
Employing two "smart card" portable appliance 600 would enable 
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the user of the providing of "credit" "smart card" to go through a 
transaction process in which said user provides proper 
identification (for example, a password) and identifies a "public 
key" identifying another "smart card" portable appliance 2600. 
The other portable appliance 2600 could use acceptance 
processes, and provide proper identification for a digital 
signature (and the credit and/or currency sender may also 
digitally sign a transaction certificate so the sending act may not 
be repudiated and this certificate may accompany the credit 
and/or currency as VDE container content. The transactions may 
involve, for example, user interface interaction that stipulates 
interest and/or other terms of the transfer. It may employ 
templates for common transaction types where the provider of 
the credit is queried as to certain parameters describing the 
agreement between the parties. The receiving portable appliance 
2600 may iteratively or as a whole be queried as to the 
acceptance of the terms. VDE negotiation techniques described 
elsewhere in this application may be employed in a smart card 
transfer of electronic credit and/or currency to another VDE 
smart card or other VDE installation. 

Such VDE electronic appliance 600/portable appliance 
2600 credit transfer features would significantly reduce the 
overhead cost of managing certain electronic credit and/or 
currency activities by significantly automating these processes 
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through extending the computerization of credit control and 
credit availability that was begun with credit cards and extended 
with debit cards. The automation of credit extension and/or 
currency transfer and the associated distributed processing 
advantages described, including the absence of any requirement 
for centralized processing and telecommunications during each 
transaction, truly make credit and/or currency, for many 
consumers and other electronic currency and/or credit users, an 
efficient, trusted, and portable commodity. 

The portable appliance 2600 or other VDE electronic 
appliance 600, can, in one embodiment, also automate many tax 
collection functions. A VDE electronic appliance 600 may, with 
great security, record financial transactions, identify the nature 
of the transaction, and identify the required sales or related 
government transaction taxes, debit the taxes from the users 
available credit, and securely communicate this information to 
one or more government agencies directly at some interval (for 
example monthly), and/or securely transfer this information to, 
for example, a financial clearinghouse, which would then transfer 
one or more secure, encrypted (or unsecure, calculated by 
clearinghouse, or otherwise computed) information audit packets 
(e.g., VDE content containers and employing secure VDE 
communication techniques) to the one or more appropriate, 
participating government agencies. The overall integrity and 
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security of VDE 100 could ensure, in a coherent and centralized 
manner, that electronic reporting of tax related information 
(derived from one or more electronic commerce activities) would 
be valid and comprehensive. It could also act as a validating 
source of information on the transfer of sales tax collection (e.g., 
if, for example, said funds are transferred directly to the 
government by a commercial operation and/or transferred in a 
manner such that reported tax related information cannot be 
tampered with by other parties in a VDE pathway of tax 
information handling). A government agency could select 
transactions randomly, or some subset or all of the reported 
transactions for a given commercial operation can be selected. 
This could be used to ensure that the commercial operation is 
actually paying to the government all appropriate collected funds 
required for taxes, and can also ensure that end-users are 
charged appropriate taxes for their transactions (including 
receipt of interest from bank accounts, investments, gifts, etc. 

Portable appliance 2600 financial and tax processes could 
involve template mechanisms described elsewhere herein. While 
such an electronic credit and/or currency management capability 
would be particularly interesting if managed at least in part, 
through the use of a portable appliance 2600, credit and/or 
currency transfer and similar features would also be applicable 



691 



WO 96/27155 



PCT/US96/02303 



for non-portable VDE electronic appliance 600's connected to or 
installed within a computer or other electronic device. 

User Notification Exception Interface ("Pop Up? 686 

As described above, the User Modification Exception 
Interface 686 may be a set of user interface programs for 
handling common VDE functions. These applications may be 
forms of VDE templates and are designed based upon certain 
assumptions regarding important options, specifically, 
appropriate to a certain VDE user model and important 
messages that must be reported given certain events A primary 
function of the "pop-up" user interface 686 is to provide a simple, 
consistent user interface to, for example, report metering events 
and exceptions (e.g., any condition for which automatic 
processing is either impossible or arguably undesirable) to the 
user, to enable the user to configure certain aspects of the 
operation of her electronic appliance 600 and, when appropriate, 
to allow the user to interactively control whether to proceed with 
certain transaction processes. If an object contains an exception 
handling method, that method will control how the "pop-up" user 
interface 686 handles specific classes of exceptions. 

The "pop-user" interface 686 normally enables handling of 
tasks not dedicated to specific objects 300, such as for example: 
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• Logging onto an electronic appliance 600 and/or entering 
into a VDE related activity or class of activities, 

• Configuring an electronic appliance 600 for a registered 
user, and/or generally for the installation, with regard to 
user preferences, and automatic handling of certain types 
of exceptions, 

• Where appropriate, user selecting of meters for use with 
specific properties, and 

• Providing an interface for communications with other 
electronic appliances 600, including requesting and/or for 
purchasing or leasing content from distributors, requesting 
clearinghouse credit and/or budgets from a clearinghouse, 
sending and/or receiving information to and/or from other 
electronic appliances, and so on. 

Figure 72A shows an example of a common "logon" VDE 
electronic appliance 600 function that may use user interface 
686. "Log-on" can be done by entering a user name, account 
name, and/or password. As shown in the provided example, a 
configuration option provided by the "pop-up" user interface 686 
dialog can be "Login at Setup", which, if selected, will initiate a 
VDE Login procedure automatically every time the user's 
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electronic appliance 600 is turned on or reset. Similarly, the 
"pop-tip" user interface 686 could provide an interface option 
called "Login at Type" which, if selected, will initiate a procedure 
automatically every time, for example, a certain type of object or 
specific content type application is opened such as a file in a 
certain directory, a computer application or file with a certain 
identifying extension, or the like. 

Figure 72B shows an example of a "pop-up" user interface 
686 dialog that is activated when an action by the user has been 
"trapped," in this case to warn the user about the amount of 
expense that will be incurred by the user's action, as well as to 
alert the user about the object 300 which has been requested and 
what that particular object will cost to use. In this example, the 
interface dialog provides a button allowing the user to request 
further detailed information about the object, including full text 
descriptions, a list of associated files, and perhaps a history of 
past usage of the object including any residual rights to use the 
object or associated discounts. 

The "Cancel" button 2660 in Figure 72B cancels the user's 
trapped request. "Cancel" is the default in this example for this 
dialog and can be activated, for example, by the return and enter 
keys on the user's keyboard 612, by a "mouse click" on that 
button, by voice command, or other command mechanisms. The 
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"Approve button" 2662, which must be explicitly selected by a 
mouse click or other command procedure, allows the user to 
approve the expense and proceed. The "More options" control 
2664 expands the dialog to another level of detail which provides 
further options, an example of which is shown in Figure 72C. 

Figure 72C shows a secondary dialog that is presented to 
the user by the "pop-up" user interface 686 when the "More 
options" button 2664 in Figure 72B is selected by the user. As 
shown, this dialog includes numerous buttons for obtaining 
further information and performing various tasks. 

In this particular example, the user is permitted to set 
"limits" such as, for example, the session dollar limit amount 
(field 2666), a total transaction dollar limit amount (field 2668), a 
time limit (in minutes) (field 2670), and a "unit limit" (in number 
of units such as paragraphs, pages, etc.) (field 2672). Once the 
user has made her selections, she may "click on" the OKAY 
button (2674) to confirm the limit selections and cause them to 
take effect. 

Thus, pop-up user interface dialogues can be provided to 
specify user preferences, such as setting limits on budgets and/or 
other aspects of object content usage during any one session or 
over a certain duration of time or until a certain point in time. 
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Dialogs can also be provided for selecting object related usage 
options such as selecting meters and budgets to be used with one 
or more objects. Selection of options may be applied to types 
(that is classes) of objects by associating the instruction with one 
or more identifying parameters related to the desired one or more 
types. User specified configuration information can set default 
values to be used in various situations, and can be used to limit 
the number or type of occasions on which the user's use of an 
object is interrupted by a "pop-up" interface 686 dialog. For 
example, the user might specify that a user request for VDE 
protected content should be automatically processed without 
interruption (resulting from an exceptions action) if the 
requested processing of information will not cost more than 
$25.00 and if the total charge for the entire current session 
(and/or day and/or week, etc.) is not greater than $200.00 and if 
the total outstanding and unpaid charge for use hasn't exceeded 
$2500.00. 

Pop-up user interface dialogs may also be used to notify the 
user about significant conditions and events. For example, 
interface 686 may be used to: 

• remind the user to send audit information to a 
clearinghouse, 
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• inform a user that a budget value is low and needs 
replenishing, 

• remind the user to back up secure database 610, and 

• inform the user about expirations of PERCs or other 
dates/times events. 

Other important "pop-up" user interface 686 functions 
include dialogs which enable flexible browsing through libraries 
of properties or objects available for licensing or purchase, either 
from locally stored VDE protected objects and/or from one or 
more various, remotely located content providers. Such function 
may be provided either while the user's computer is connected to 
a remote distributor's or clearinghouse's electronic appliance 600, 
or by activating an electronic connection to a remote source after 
a choice (such as a property, a resource location, or a class of 
objects or resources is selected). A browsing interface can allow 
this electronic connection to be made automatically upon a user 
selection of an item, or the connection itself can be explicitly 
activated by the user. See Figure 72D for an example of such a 
"browsing" dialog. 
Smart Objects 

VDE 100 extends its control capabilities and features to 
"intelligent agents." Generally, an "intelligent agent" can act as 
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an emissary to allow a process that dispatches it to achieve a 
result the originating process specifies. Intelligent agents that 
are capable of acting in the absence of their dispatch process are 
particularly useful to allow the dispatching process to access, 
through its agent, the resources of a remote electronic appliance. 
In such a scenario, the dispatch process may create an agent 
(e.g., a computer program and/or control information associated 
with a computer program) specifying a particular desired task(s), 
and dispatch the agent to the remote system. Upon rea chin g the 
remote system, the "agent" may perform its assigned task(s) 
using the remote system's resources. This allows the dispatch 
process to, in effect, extend its capabilities to remote systems 
where it is not present. 

Using an "agent" in this manner increases flexibility. The 
dispatching process can specify, through its agent, a particular 
desired task(s) that may not exist or be available on the remote 
system. Using such an agent also provides added trustedness; 
the dispatch process may only need to "trust" its agent, not the 
entire remote system. Agents have additional advantages. 

Software agents require a high level of control and 
accountability to be effective, safe and useful. Agents in the form 
of computer viruses have had devastating effects worldwide. 
Therefore, a system that allows an agent to access it should be 
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able to control it or otherwise prevent the agent from damaging 
important resources. In addition, systems allowing themselves to 
be accessed by an agent should sufficiently trust the agent and/or 
provide mechanisms capable of holding the true dispatcher of the 
agent responsible for the agent's activities. Similarly, the 
dispatching process should be able to adequately limit and/or 
control the authority of the agents it dispatches or else it might 
become responsible for unforeseen activities by the agent (e.g., 
the agent might run up a huge bill in the course of following 
imprecise instructions it was given by the process that dispatched 
it). 



These significant problems in using software agents have 
not be adequately addressed in the past. The open, flexible 
control structures provided by VDE 100 addresses these 
problems by providing the desired control and accountability for 
software agents (e.g., agent objects). For example, VDE 100 
positively controls content access and usage, provides guarantee 
of payment for content used, and enforces budget limits for 
accessed content. These control capabilities are well suited to 
controlling the activities of a dispatched agent by both the 
process that dispatches the agent and the resource accessed by 
the dispatched agent. 
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One aspect of the preferred embodiment provided by the 
present invention provides a "smart object" containing an agent. 
Generally, a "smart object" may be a VDE object 300 that 
contains some type(s) of software programs ("agents") for use 
with VDE control information at a VDE electronic appliance 600. 
A basic "smart object" may comprise a VDE object 300 that, for 
example, contains (physically and/or virtually): 

a software agent, and 

at least one rule and/or control associated with the 

software agent that governs the agent's operation. 
Although this basic structure is sufficient to define a "smart 
object," Figure 73 shows a combination of containers and control 
information that provides one example of a particularly 
advantageous smart object structure for securely managing and 
controlling the operation of software agents. 

As shown in Figure 73, a smart object 3000 may be 
constructed of a container 300, within which is embedded one or 
more further containers (300z, 300y, etc.). Container 300 may 
further contain rules and control information for accessing and 
using these embedded containers 300z, 300y, etc. Container 300z 
embedded in container 300 is what makes the object 3000 a 
"smart object." It contains an "agent" that is managed and 
controlled by VDE 100. 
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The rules and control information 806f associated with 
container 300z govern the circumstances under which the agent 
may be released and executed at a remote VDE site, including 
any limitations on execution based on the cost of execution for 
example. This rule and control information may be specified 
entirely in container 300z, and/or may be delivered as part of 
container 300, as part of another container (either within 
container 300 or a separately deliverable container), and/or may 
be already present at the remote VDE site. 

The second container 300y is optional, and contains 
content that describes the locations at which the agent stored in 
container 300z may be executed. Container 300y may also 
contain rules and control information 806e that describe the 
manner in which the contents of container 300y may be used or 
altered. This rule and control information 806e and/or further 
rules 300y(l) also contained within container 300y may describe 
searching and routing mechanisms that may be used to direct the 
smart object 3000 to a desired remote information resource. 
Container 300y may contain and/or reference rules and control 
information 300y(l) that specify the manner in which searching 
and routing information use and any changes may be paid for. 

Container 300x is an optional content container that is 
initially "empty" when the smart object 3000 is dispatched to a 
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remote site. It contains rules and control information 300x(l) for 
storing the content that is retrieved by the execution of the agent 
contained in container 300z. Container 300x may also contain 
limits on the value of content that is stored in the retrieval 
container so as to limit the amount of content that is retrieved. 

Other containers in the container 300 may include 
administrative objects that contain audit and billing trails that 
describe the actions of the agent in container 300z and any 
charges incurred for executing an agent at a remote VDE node. 
The exact structure of smart object 3000 is dependent upon the 
type of agent that is being controlled, the resources it will need 
for execution, and the types of information being retrieved. 

The smart object 3000 in the example shown in Figure 73 
may be used to control and manage the operation of an agent in 
VDE 100. The following detailed explanation of an example 
smart object transaction shown in Figure 74 may provide a 
helpful, but non-limiting illustration. In this particular example, 
assume a user is going to create a smart object 3000 that 
performs a library search using the "Very Fast and Efficient" 
software agent to search for books written about some subject of 
interest (e.g., "fire flies"). The search engine is designed to return 
a list of books to the user. The search engine in this example 
may spend no more than $10.00 to find the appropriate books, 
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may spend no more than $3.00 in library access or 
communications charges to get to the library, and may retrieve 
no more than $15.00 in information. All information relating to 
the search or use is to be returned to the user and the user will 
permit no information pertaining to the user or the agent to be 
released to a third party. 

In this example, a dispatching VDE electronic appliance 
3010 constructs a smart object 3000 like the one shown in Figure 
73. The rule set in 806a is specified as a control set that contains 
the following elements: 

1. a smart_agent_execution event that specifies the 
smart agent is stored in embedded container 300z 
and has rules controlling its execution specified in 
that container; 

2. a smart_agent_use event that specifies the smart 
agent will operate using information and parameters 
stored in container 300; 

3. a routing_use event that specifies the information 
routing information is stored in container 300y and 
has rules controlling this information stored in that 
container; 
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4. an information_write event that specifies 

information written will be stored in container 300y, 
300x, or 300w depending on its type (routing, 
retrieved, or administrative), and that these 
containers have independent rules that control how 
information is written into them. 

The rule set in control set 806b contains rules that specify 
the rights desired by this smart object 3000. Specifically, this 
control set specifies that the software agent desires: 

1. A right to use the "agent execution" service on the 
remote VDE site. Specific billing and charge 
information for this right is carried in container 
300z. 

2. A right to use the "software description list" service 
on the remote VDE site. Specific billing and charge 
information for this for this right is carried in 
container 300y. 

3. A right to use an "information locator service" on a 
remote VDE site. 
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4. A right to have information returned to the user 
without charge (charges to be incurred on release of 
information and payment will be by a VISA budget) 

5. A right to have all audit information returned such 
that it is readable only by the sender. 

The rule set in control set 806c specifies that container 
300w specifies the handling of all events related to its use. The 
rule set in control set 806d specifies that container 300x specifies 
the handling of all events related to its use. The rule set in 
control set 806e specifies that container 300y specifies the 
handling of all events related to its use. The rule set in control 
set 806f specifies that container 300z specifies the handling of all 
events related to its use. 

Container 300z is specified as containing the "Very Fast 
and Efficient" agent content, which is associated with the 
following rules set: 

1. A use event that specifies a meter and VISA budget 
that limits the execution to $10.00 charged against 
the owner's VISA card. Audits of usage are required 
and will be stored in object 300w under control 
information specified in that object. 
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After container 300z and its set are specified, they are 
constructed and embedded in the smart object container 300. 

Container 300y is specified as a content object with two 
types of content. Content type A is routing information and is 
read/write in nature. Content type A is associated with a rules 
set that specifies: 

1. A use event that specifies no operation for the 
release of the content. This has the effect of not 
charging for the use of the content. 



2. A write event that specifies a meter and a VISA 

budget that limits the value of writing to $3.00. The 
billing method used by the write is left unspecified 
and will be specified by the control method that uses 
this rule. 



3. Audits of usage are required and will be stored in 
object 300w under control information specified in 
that object. 



Content type B is information that is used by the software 
agent to specify parameters for the agent. This content is 
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specified as the string "fire fly" or "fire flies". Content type B is 
associated with the following rule set: 

1. A use event that specifies that the use may only be 
by the software agent or a routing agent. The 
software agent has read only permission, the routing 
agent has read/write access to the information. 
There are no charges associated with using the 
information, but two meters; one by read and one by 
write are kept to track use of the information by 
various steps in the process. 

2. Audits of usage are required and will be stored in 
object 300w under control information specified in 
that object. 

After container 300y and its control sets are specified, they 
are constructed and embedded in the smart object container 300. 

Container 300x is specified as a content object that is 
empty of content. It contains a control set that contains the 
following rules: 
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1. A write jwithoutjbilling event that specifies a meter 
and a general budget that limits the value of writing 
to $15.00. 



2. Audits of usage are required and will be stored in 
object 300w under control information specified in 
that object. 



3. An empty use control set that may be filled in by the 
owner of the information using predefined methods 
(method options). 

After container 300x and its control sets are specified, they 
are constructed and embedded in the smart object container 300. 

Container 300 w is specified as an empty administrative 
object with a control set that contains the following rules: 

1. A use event that specifies that the information 
contained in the administrative object may only be 
released to the creator of smart object container 300. 

2. No other rules may be attached to the administrative 
content in container 300w. 
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After container 300w and its control sets are specified, they 
are constructed and embedded in the smart object container 300. 

At this point, the smart object has been constructed and is 
ready to be dispatched to a remote VDE site. The smart object is 
sent to a remote VDE site (e.g., using electronic mail or another 
transport mechanism) that contains an information locator 
service 3012 via path 3014. The smart object is registered at the 
remote site 3012 for the "item locator service." The control set in 
container related to "item locator service" is selected and the 
rules contained within it activated at the remote site 3012. The 
remote site 3012 then reads the contents of container 300y under 
the control of rule set 806f and 300y(l), and permits writes of a 
list of location information into container 300y pursuant to these 
rules. The item locator service writes a list of three items into the 
smart object, and then "deregisters" the smart object (now 
containing the location information) and sends it to a site 3016 
specified in the list written to the smart object via path 3018. In 
this example, the user may have specified electronic mail for 
transport and a list of remote sites that may have the desired 
information is stored as a forwarding list. 

The smart object 3000, upon arriving at the second remote 
site 3016, is registered with that second site. The site 3016 
provides agent execution and software description list services 
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compatible with VDE as a service to smart objects. It publishes 
these services and specifies that it requires $10.00 to start the 
agent and $20/piece for all information returned. The 
registration process compares the published service information 
against the rules stored within the object and determines that an 
acceptable overlap does not exist. Audit information for all these 
activities is written to the administrative object 300w. The 
registration process then fails (the object is not registered), and 
the smart object is forwarded by site 3016 to the next VDE site 
3020 in the list via path 3022. 

The smart object 3000, upon arriving at the third remote 
site 3020, is registered with that site. The site 3020 provides 
agent execution and software description list services compatible 
with VDE as a service to smart objects. It publishes these 
services and specifies that it requires $1.00 to start the agent and 
$0.50/piece for all information returned. The registration process 
compares the published service information against the rules 
stored within the object and determines that an acceptable 
overlap exists. The registration process creates a URT that 
specifies the agreed upon control information. This URT is used 
in conjunction with the other control information to execute the 
software agent under VDE control. 
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The agent software starts and reads its parameters out of 
container 300y. It then starts searching the database and 
obtains 253 "hits" in the database. The list of hits is written to 
container 300x along with a completed control set that specifies 
the granularity of each item and that each item costs $0.50. Upon 
completion of the search, the budget for use of the service is 
incremented by $1.00 to reflect the use charge for the service. 
Audit information for all these activities is written to the 
administrative object 300w. 

The remote site 3020 returns the now "full" smart object 
3000 back to the original sender (the user) at their VDE node 
3010 via path 3024. Upon arrival, the smart object 3000 is 
registered and the database records are available. The control 
information specified in container 300x is now a mix of the 
original control information and the control information specified 
by the service regarding remote release of their information. The 
user then extracts 20 records from the smart object 3000 and has 
$10.00 charged to her VISA budget at the time of extraction. 

In the above smart agent VDE examples, a certain 
organization of smart object 3000 and its constituent containers 
is described. Other organizations of VDE and smart object 
related control information and parameter data may be created 
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and may be used for the same purposes as those ascribed to 
object 3000 in the above example. 

Negotiation and Electronic Contracts 

An electronic contract is an electronic form of an 
agreement including rights, restrictions, and obligations of the 
parties to the agreement. In many cases, electronic agreements 
may surround the use of digitally provided content; for example, 
a license to view a digitally distributed movie. It is not required, 
however, that an electronic agreement be conditioned on the 
presence or use of electronic content by one or more parties to the 
agreement. In its simplest form, an electronic agreement 
contains a right and a control that governs how that right is 
used. 

Electronic agreements, like traditional agreements, may be 
negotiated between their parties (terms and conditions submitted 
by one or more parties may simply be accepted (cohesion 
contract) by one or more other parties and/or such other parties 
may have the right to select certain of such terms and conditions 
(while others may be required)). Negotiation is defined in the 
dictionary as "the act of bringing together by mutual agreement." 
The preferred embodiment provides electronic negotiation 
processes by which one or more rights and associated controls can 
be established through electronic automated negotiation of terms. 
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Negotiations normally require a precise specification of rights 
and controls associated with those rights. PERC and URT 
structures provide a mechanism that may be used to provide 
precise electronic representations of rights and the controls 
associated with those rights. VDE thus provides a "vocabulary" 
and mechanism by which users and creators may specify their 
desires. Automated processes may interpret these desires and 
negotiate to reach a common middle ground based on these 
desires. The results of said negotiation may be concisely 
described in a structure that may be used to control and enforce 
the results of the electronic agreement. VDE farther enables this 
process by providing a secure execution space in which the 
negotiation process(es) are assured of integrity and 
confidentiality in their operation. The negotiation process(es) 
may also be executed in such a manner that inhibits external 
tampering with the negotiation. 

A final desirable feature of agreements in general (and 
electronic representations of agreements in particular) is that 
they be accurately recorded in a non-repudiatable form. In 
traditional terms, this involves creating a paper document (a 
contract) that describes the rights, restrictions, and obligations of 
all parties involved. This document is read and then signed by 
all parties as being an accurate representation of the agreement. 
Electronic agreements, by their nature, jnay not be initially 
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rendered in paper. VDE enables such agreements to be 
accurately electronically described and then electronically signed 
to prevent repudiation. In addition, the preferred embodiment 
provides a mechanism by which human-readable descriptions of 
terms of the electronic contract can be provided. 

VDE provides a concise mechanism for specifying control 
sets that are VDE site interpretable. Machine interpretable 
mechanisms are often not human readable. VDE often operates 
the negotiation process on behalf of at least one human user. It 
is thus desirable that the negotiation be expressible in "human 
readable form." VDE data structures for objects, methods, and 
load modules all have provisions to specify one or more DTDs 
within their structures. These DTDs may be stored as part of the 
item or they may be stored independently. The DTD describes 
one or more data elements (MDE, UDE, or other related data 
elements) that may contain a natural language description of the 
function of that item. These natural language descriptions 
provide a language independent, human readable description for 
each item. Collections of items (for example, a BUDGET method) 
can be associated with natural language text that describes its 
function and forms a term of an electronically specified and 
enforceable contract. Collections of terms (a control set) define a 
contract associated with a specific right. VDE thus permits the 
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electronic specification, negotiation, and enforcement of electronic 
contracts that humans can understand and adhere to. 

VDE 100 enables the negotiation and enforcement of 
electronic contracts in several ways: 

• it enables a concise specification of rights and control 
information that permit a common vocabulary and 
procedure for negotiation, 

• it provides a secure processing environment within 
which to negotiate, 

• it provides a distributed environment within which 
rights and control specifications may be securely 
distributed, 

• it provides a secure processing environment in which 
negotiated contracts may be electronically rendered 
and signed by the processes that negotiate them, and 

• it provides a mechanism that securely enforces a 
negotiated electronic contract. 
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Types of Negotiations 

A simple form of a negotiation is a demand by one party to 
form an "adhesion" contract. There are few, if any, options that 
may be chosen by the other party in the negotiation. The 
recipient of the demand has a simple option; she may accept or 
reject the terms and conditions (control information) in the 
demand. If she accepts the conditions, she is granted rights 
subject to the specified control information. If she rejects the 
conditions, she is not granted the rights. PERC and URT 
structures may support negotiation by demand; a PERC or 
control set from a PERC may be presented as a demand, and the 
recipient may accept or reject the demand (selecting any 
permitted method options if they are presented). 

A common example of this type of negotiation today is the 
purchase of software under the terms of a "shrink-wrap license." 
Many widely publicized electronic distribution schemes use this 
type of negotiation. CompuServe is an example of an on-line 
service that operates in the same manner. The choice is simple: 
either pay the specified charge or don't use the service or 
software. VDE supports this type of negotiation with its 
capability to provide PERCs and URTs that describe rights and 
control information, and by permitting a content owner to provide 
a REGISTER method that allows a user to select from a set of 
predefined method options. In this scenario, the REGISTER 
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method may contain a component that is a simplified negotiation 
process. 

A more complex form of a negotiation is analogous to 
"haggling." In this scenario, most of the terms and conditions are 
fixed, but one or more terms (e.g., price or payment terms) are 
not. For these terms, there are options, limi ts, and elements that 
may be negotiated over. A VDE electronic negotiation between 
two parties may be used to resolve the desired, permitted, and 
optional terms. The result of the electronic negotiation may be a 
finalized set of rules and control information that specify a 
completed electronic contract. A simple example is the scenario 
for purchasing software described above adding the ability of the 
purchaser to select a method of payment (VISA, Mastercard, or 
American Express). A more complex example is a scenario for 
purchasing information in which the price paid depends on the 
amount of information about the user that is returned along with 
a usage audit trail. In this second example, the right to use the 
content may be associated with two control sets. One control set 
may describe a fixed ("higher") price for using the content. 
Another control set may describe a fixed ("lower") price for using 
the content with additional control information and field 
specifications requiring collection and return the user's personal 
information. In both of these cases, the optional and permitted 
fields and control sets in a PERC may describe the options that 
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may be selected as part of the negotiation. To perform the 
negotiation, one party may propose a control set containing 
specific fields, control information, and limits as specified by a 
PERC; the other party may pick and accept from the control sets 
proposed, reject them, or propose alternate control sets that 
might be used. The negotiation process may use the permitted, 
required, and optional designations in the PERC to determine an 
acceptable range of parameters for the final rule set. Once an 
agreement is reached, the negotiation process may create a new 
PERC and/or URT that describes the result of the negotiation. 
The resulting PERCs and/or URTs may be "signed" (e.g., using 
digital signatures) by all of the negotiation processes involved in 
the negotiation to prevent repudiation of the agreement at a later 
date. 

Additional examples of negotiated elements are: electronic 
cash, purchase orders, purchase certificates (gift certificates, 
coupons), bidding and specifications, budget "rollbacks" and 
reconciliation, currency exchange rates, stock purchasing, and 
billing rates. 

A set of PERCs that might be used to support the second 
example described above is presented in Figures 75A (PERC sent 
by the content owner), 75B (PERC created by user to represent 
their selections and rights), and 75C (PERC for controlling the 
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negotiation process). These PERCs might be used in conjunction 
with any of the negotiation process(es) and protocols described 
later in this section. 

Figure 75A shows an example of a PERC 3100 that might 
be created by a content provider to describe their rights options. 
In this example, the PERC contains information regarding a 
single USE right. Two alternate control sets 3102a, 3102b are 
presented for this right in the example. Control set 3102a 
permits the use of the content without passing back information 
about the user, and another control set 3102b permits the use of 
the content and collects "response card" type information from 
the user. Both control sets 3102a, 3102b may use a common set 
of methods for most of the control information. This common 
control information is represented by a CSR 3104 and CS0 3106. 

Control set 3102a in this PERC 3100 describes a 
mechanism by which the user may obtain the content without 
providing any information about its user to the content provider. 
This control set 3102a specifies a well-known vending control 
method and set of required methods and method options. 
Specifically, in this example, control set 3102a defines a 
BUDGET method 3108 (e.g., one of VISA, Mastercard, or 
American Express) and it defines a BILLING method 3110 that 
specifies a charge (e.g., a one-time charge of $100.00). 



719 



WO 96/27155 



PCT/US96/02303 



Control set 3102b in this PERC 3100 describes another 
mechanism by which the user may obtain the content. In this 
example, the control set 3102b specifies a different vending 
control method and a set of required methods and method 
options. This second control set 3102b specifies a BUDGET 
method 3112 (e.g., one of VISA, Mastercard, or American 
Express), a BILLING method 3116 that specifies a charge (e.g., a 
lesser one-time charge such as $25.00) and an AUDIT method 
3114 that specifies a set of desired and required fields. The 
required and desired field specification 3116 may take the form of 
a DTD specification, in which, for example, the field names are 
listed. 

The content creator may "prefer" one of the two control sets 
(e.g., control set 2) over the other one. If so, the "preferred" 
control set may be "offered" first in the negotiation process, and 
withdrawn in favor of the "non-preferred" control set if the other 
party to the negotiation "rejects" the "preferred" control set. 

In this example, these two control sets 3102a, 3102b may 
share a common BUDGET method specification. The BUDGET 
method specification may be included in the CSR 3104 or CS0 
3106 control sets if desired. Selecting control set 3102a (use with 
no information passback) causes a unique component assembly to 
be assembled as specified by the PERC 3100. Specifically, in this 
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example it selects the "Vending" CONTROL method 3118, the 
BILLING method 3110 for a $100 fixed charge, and the rest of 
the control information specified by CSR 3104 and CSO 3106. It 
also requires the user to specify her choice of acceptable 
BUDGET method (e.g., from the list including VISA, Mastercard, 
and American Express). Selecting control set 3102b assembles a 
different component assembly using the "Vending with 'response 
card'" CONTROL method 3120, the BILLING method 3116 (e.g., 
for a $25 fixed charge), an AUDIT method 3114 that requires the 
fields listed in the Required Fields DTD 3116. The process may 
also select as many of the fields listed in the Desired Fields DTD 
3116 as are made available to it. The rest of the control 
information is specified by CSR 3104 and CSO 3106. The 
selection of control set 3102b also forces the user to specify their 
choice of acceptable BUDGET methods (e.g., from the list 
including VISA, Mastercard, and American Express). 

Figure 75B shows an example of a control set 3125 that 
might be used by a user to specify her desires and requirements 
in a negotiation process. This control set has a USE rights 
section 3127 that contains an aggregated CSR budget 
specification 3129 and two optional control sets 3131a, 3131b for 
use of the content. Control set 3131a requires the use of a 
specific CONTROL method 3133 and AUDIT method 3135. The 
specified AUDIT method 3135 is parameterized with a list of 
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fields 3137 that may be released in the audit trail. Control set 
3131a also specifies a BILLING method 3139 that can cost no 
more than a certain amount (e.g., $30.00). Control set 3131b in 
this example describes a specific CONTROL method 3141 and 
may reference a BILLING method 3143 that can cost no more 
than a certain amount (e.g., $150.00) if this option is selected. 

Figure 75E shows a more high-level view of an electronic 
contract 3200 formed as a "result" of a negotiation process as 
described above. Electronic contract 3200 may include multiple 
clauses 3202 and multiple digital signatures 3204. Each clause 
3202 may comprise a PERC/URT such as item 3160 described 
above and shown in Figure 75D. Each "clause" 3202 of electronic 
contract 3200 thus corresponds to a component assembly 690 
that may be assembled and executed by a VDE electronic 
appliance 600. Just as in normal contracts, there may be as 
many contract clauses 3202 within electronic contract 3200 as is 
necessary to embody the "agreement" between the "parties." 
Each of clauses 3202 may have been electronically negotiated 
and may thus embody a part of the "agreement" (e.g., a 
"compromise") between the parties. Electronic contract 3200 is 
"self-executing" in the sense that it may be literally executed by a 
machine, i.e., a VDE electronic appliance 600 that assembles 
component assemblies 690 as specified by various electronic 
clauses 3202. Electronic contract 3200 may be automatically 
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"enforced" using the same VDE mechanisms discussed above that 
are used in conjunction with any component assembly 690. For 
example, assuming that a clause 3202(2) corresponds to a 
payment or BILLING condition or term, its corresponding 
component assembly 690 when assembled by a user's VDE 
electronic appliance 600 may automatically determine whether 
conditions are right for payment and, when they are, 
automatically access an appropriate payment mechanism (e.g., a 
virtual "credit card" object for the user) to arrange that payment 
to be made. As another example, assuming that electronic 
contract clause N 3202(N) corresponds to a user's obligation to 
provide auditing information to a particular VDE participant, 
electronic contract 3200 will cause VDE electronic appliance 600 
to assemble a corresponding component assembly 690 that may, 
for example, access the appropriate audit trails within secure 
database 610 and provide them in an administrative object to the 
correct participant. Figure 75F shows that clause 3202(N) may, 
for example, specify a component assembly 690 that arranges for 
multiple steps in a transaction 3206 to occur. Some of these steps 
(e.g., step 3208(4), 3208(5)) may be conditional on a test (e.g., 
3208(3)) such as, for example, whether content usage has 
exceeded a certain amount, whether a certain time period has 
expired, whether a certain calendar date has been reached, etc. 
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Digital signatures 3204 shown in the Figure 75E electronic 
contract 3200 may comprise, for example, conventional digital 
signatures using public key techniques as described above. Some 
electronic contracts 3200 may not bear any digital signatures 
3204. However, it may be desirable to require the electronic 
appliance 600 of the user who is a party to the electronic contract 
3200 to digitally "sign" the electronic contract so that the user 
cannot later repudiate the contract, for evidentiary purposes, etc. 
Multiple parties to the same contract may each digitally "sign" 
the same electronic contract 3200 similarly to the way multiple 
parties to a contract memorialized in a written instrument use an 
ink pen to sign the instrument. 

Although each of the clauses 3202 of electronic contract 
3200 may ultimately correspond to a collection of data and code 
that may be executed by a PPE 650, there may in some instances 
be a need for rendering a human readable version of the 
electronic contract. This need can be accommodated by, as 
mentioned above, providing text within one or more DTDs 
associated with the component assembly or assemblies 690 used 
to "self-execute" the contract. Such text might, for example, 
describe from a functional point of view what the corresponding 
electronic contract clause 3202 means or involves, and/or might 
describe in legally enforceable terms what the legal obligation 
under the contract is or represents. "Templates" (described 
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elsewhere herein) might be used to supply such text from a text 
library. An expert system and/or artificial intelligence capability 
might be used to impose syntax rules that bind different textual 
elements together into a coherent, humanly readable contract 
document. Such text could, if necessary, be reviewed and 
modified by a "human" attorney in order customize it for the 
particular agreement between the parties and/or to add further 
legal obligations augmenting the "self-executing" electronic 
obligations embodied within and enforced by the associated 
component assemblies 690 executing on a VDE electronic 
appliance 600. Such text could be displayed automatically or on 
demand upon execution of the electronic contract, or it could be 
used to generate a printed humanly-readable version of the 
contract at any time. Such a document version of the electronic 
contract 3200 would not need to be signed in ink by the parties to 
the agreement (unless desired) in view of the fact that the digital 
signatures 3204 would provide a sufficiently secure and trusted 
evidentiary basis for proving the parties' mutual assent to all the 
terms and conditions within the contract. 

In the preferred embodiment, the negotiation process 
executes within a PPE 650 under the direction of a further PERC 
-that specifies the process. Figure 75C shows an example of a 
PERC 3150 that specifies a negotiation process. The PERC 3150 
contains a single right 3152 for negotiation, with two permitted 
control sets 3154a, 3154b described for that right. The first 
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control set 3154a may be used for a "trusted negotiation"; it 
references the desired negotiation CONTROL method 
("Negotiate") 3156 and references (in fields 3157a, 3157b) two 
UDEs that this CONTROL method will use. These UDEs may 
be, for example, the PERCs 3100, 3125 shown in Figures 75A and 
75B. The second control set 3154b may be used by "multiple 
negotiation" processes to manage the negotiation, and may 
provide two negotiation methods: "Negotiatel," and "Negotiate2". 
Both negotiation processes may be described as required methods 
("Negotiatel" and "Negotiate2") 3156, 3158 that take respective 
PERCs 3100, 3125 as their inputs. The CONTROL method 3158 
for this control set in this example may specify the name of a 
service that the two negotiation processes will use to 
communicate with each other, and may also manage the creation 
of the URT resulting from the negotiation. 

When executed, the negotiation process(es) specified by the 
PERC 3150 shown in Figure 75C may be provided with the 
PERCs 3100, 3125 as input that will be used as the basis for 
negotiation. In this example, the choice of negotiation process 
type (trusted or multiple) may be made by the executing VDE 
node. The PERC 3150 shown in Figure 75C might be, for 
example, created by a REGISTER method in response to a 
register request from a user. The process specified by this PERC 
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3150 may then be used by a REGISTER method to initiate 
negotiation of the terms of an electronic contract. 

During this example negotiation process, the PERCs 3100, 
3125 shown in Figures 75A and 75B act as input data structures 
that are compared by a component assembly created based on 
PERC 3150 shown in Figure 35C. The component assembly 
specified by the control sets may be assembled and compared, 
starting with required "terms," and progressing to 
preferred/desired "terms" and then moving on to permitted 
"terms," as the negotiation continues. Method option selections 
are made using the desired method and method options specified 
in the PERCs 3100, 3125. In this example, a control set for the 
PERC 3100 shown in Figure 75A may be compared against the 
PERC 3125 shown in Figure 75B. If there is a "match," the 
negotiation is successfully concluded and "results" are generated. 

In this embodiment, the results of such negotiation will 
generally be written as a URT and "signed" by the negotiation 
process(es) to indicate that an agreement has been reached. 
These electronic signatures provide the means to show that a 
(virtual) "meeting of minds" was reached (one of the traditional 
legal preconditions for a contract to exist). An example of the 
URT 3160 that would have been created by the above example is 
shown in Figure 75D. 
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This URT 3160 (which may itself be a PERC 808) includes 
a control set 3162 that reflects the "terms" that were "agreed 
upon" in the negotiation. In this example, the "agreed upon" 
terms must "match" terms required by input PERCs 3100, 3125 
in the sense that they must be "as favorable as" the terms 
required by those PERCs. The negotiation result shown includes, 
for example, a "negotiated" control set 3162 that in some sense 
corresponds to the control set 3102a of the Figure 75A PERC 
3100 and to the control set 3131a of the Figure 75B control set 
3125. Resulting "negotiated" control set 3162 thus includes a 
required BUDGET method 3164 that corresponds to the control 
set 3125 desired BUDGET method 3142 but which is "within" the 
range of control sets allowed by control set 3100 required 
BUDGET method 3112. Similarly, resulting negotiated control 
set 3162 includes a required AUDIT method 3166 that complies 
with the requirements of both PERC 3100 required AUDIT 
method 3114 and PERC 3125 required AUDIT method 3135. 
Similarly, resulting negotiated control set 3162 includes a 
required BILLING method 3170 that "matches" or complies with 
each of PERC 3100 required BILLING method 3116 and PERC 
3125 required BILLING method 3170. 

Another class of negotiation is one under which no rules 
are fixed and only the desired goals are specified. The 
negotiation processes for this type of negotiation may be very 
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complex. It may utilize artificial intelligence, fuzzy logic, and/or 
related algorithms to reach their goals. VDE supports these 
types of processes by providing a mechanism for concisely 
specifying rights, control information, fields and goals (in the 
form of desired rights, control information, and fields). Goals for 
these types of processes might be specified as one more control 
sets that contain specific elements that are tagged as optional, 
permitted, or desired. 

Types of Negotiations 

Negotiations in the preferred embodiment may be 
structured in any of the following ways: 

1 . shared knowledge 

2. trusted negotiator 

3. "zero-based" knowledge 

"Shared knowledge" negotiations are based on all parties 
knowing all of the rules and constraints associated with the 
negotiation. Demand negotiations are a simple case of shared 
knowledge negotiations; the demander presents a list of demands 
that must be accepted or rejected together. The list of demands 
comprises a complete set of knowledge required to accept or reject 
each item on the list. VDE enables this class of negotiation to 
occur electronically by providing a mechanism by which demands 
may be encoded, securely passed, and securely processed between 
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and with secure VDE subsystems using VDE secure processing, 
and communication capabilities. Other types of shared 
knowledge negotiations employed by VDE involve the exchange 
of information between two or more negotiating parties; the 
negotiation process(es) can independently determine desired final 
outcome(s) based on their independent priorities. The processes 
can then negotiate over any differences. Shared knowledge 
negotiations may require a single negotiation process (as in a 
demand type negotiation) or may involve two or more cooperative 
processes. Figures 76A and 76B illustrate scenarios in which one 
and two negotiation processes are used in a shared knowledge 
negotiation. 

Figure 76A shows a single negotiation process 3172 that 
takes any number of PERCs 808 (e.g., supplied by different 
parties) as inputs to the negotiation. The negotiation process 
3172 executes at a VDE node under supervision of "Negotiation 
Process Rules and Control information" that may be supplied by 
a further PERC (e.g., PERC 3150 shown in Figure 75C). The 
process 3172 generates one or more PERCs/URTs 3160 as results 
of the negotiation. 

Figure 76B shows multiple negotiation processes 3172A- 
3172N each of which takes as input a PERC 808 from a party 
and a further PERC 3150 that controls the negotiation process, 
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and each of which generates a negotiated "result" PERC/URT 
3160 as output. Processes 3172A-3172N may execute at the 
same or different VDE nodes and may communicate using a 
"negotiation protocol." 

Single and multiple negotiation processes may be used for 
specific VDE sites. The negotiation processes are named, and can 
be accessed using well known method names. PERCs and URTs 
may be transported in administrative or smart objects to remote 
VDE sites for processing at that site, as may the control PERCs 
and REGISTER method that controls the negotiation. 

Multiple negotiation processes require the ability to 
communicate between these processes 3172; including secure 
communication between secure processes that are present at 
physically separate VDE sites (secure subsystems). VDE 
generalizes the inter-process communication into a securely 
provided service that can be used if the configuration requires it. 
The inter-process communication uses a negotiation protocol to 
exchange information about rule sets between processes 3172. 
An example of a negotiation protocol includes the following 
negotiation primitives": 

WANT Want a set of terms and conditions 

ACCEPT Accept a set of terms and conditions 

REJECT Reject a set of terms and conditions 
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OFFER 



Offer a set of terms and conditions in 



exchange for other terms and conditions 



HAVE 



Assert a set of terms and conditions are 



possible or desirable 



QUIT 



Assert the end of the negotiation 



without reaching an agreement 
AGREEMENT Conclude the negotiation and pass the 
rule set for signature 

The WANT primitive takes rights and control set (or parts 
of control sets) information, and asserts to the other process(es) 
3172 that the specified terms are desired or required. Demand 
negotiations are a simple case of a WANT primitive being used to 
assert the demand. This example of a protocol may introduce a 
refined form of the WANT primitive, REQUIRE. In this example, 
REQUIRE allows a party to set terms that she decides are 
necessary for a contract to be formed, WANT may allow the party 
to set terms that are desirable but not essential. This permits a 
distinction between "must have" and "would like to have." 

In this example, WANT primitives must always be 
answered by an ACCEPT, REJECT, or OFFER primitive. The 
ACCEPT primitive permits a negotiation process 3172 to accept a 
set of terms and conditions. The REJECT primitive permits a 
process 3172 to reject an offered set of terms and conditions. 
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Rejecting a set of required terms and conditions may terminate 
the negotiation. OFFER permits a counter-offer to be made. 

The HAVE, QUIT, and AGREEMENT primitives permit 
the negotiation protocols to pass information about rule sets. 
Shared knowledge negotiations may, for example, start with all 
negotiation processes 3172A-3172N asserting HAVE (my PERC) 
to the other processes. HAVE is also used when an impasse is 
reached and one process 3172 needs to let the other process 3172 
know about permitted options. QUIT signals an unsuccessful 
end of the negotiation without reaching an agreement, while 
AGREEMENT signals a successful end of an agreement and 
passes the resulting "negotiated" PERC/URT 3160 to the other 
process(es) 3172 for signature. 

In "trusted negotiator" negotiations, all parties provide 
their demands and preferences to a "trusted" negotiator and 
agree to be bound by her decision. This is similar to binding 
arbitration in today's society. VDE enables this mode of 
negotiation by providing an environment in which a "trusted" 
negotiation service may be created. VDE provides not only the 
mechanism by which demands, desires, and limits may be 
concisely specified (e.g., in PERCs), but in which the PERCs may 
be securely transferred to a "trusted" negotiation service along 
with a rule set that specifies how the negotiation will be 
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conducted, and by providing a secure execution environment so 
that the negotiation process may not be tampered with. Trusted 
negotiator services can be used at VDE sites where the integrity 
of the site is well known. Remote trusted negotiation services 
can be used by VDE sites that do not possess sufficient 
computing resources to execute one or more negotiation 
process(es); they can establish a co mmu nication link to a VDE 
site that provides this service and permits the service to handle 
the negotiation on their behalf. 

"Zero-based" knowledge negotiations share some 
characteristics of the zero-based knowledge protocols used for 
authentication. It is well understood in the art how to construct 
a protocol that can determine if a remote site is the holder of a 
specific item without exchanging or exposing the item. This type 
of protocol can be constructed between two negotiation processes 
operating on at least one VDE site using a control set as their 
knowledge base. The negotiation processes may exchange 
information about their control sets, and may make demands and 
counter proposals regarding using their individual rule sets. For 
example, negotiation process A may communicate with 
negotiation process B to negotiate rights to read a book. 
Negotiation process A specifies that it will pay not more than 
$10.00 for rights to read the book, and prefers to pay between 
$5.00 and $6.00 for this right. Process A's rule set also specifies 
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that for the $5.00 option, it will permit the release of the reader's 
name and address. Process B's rule set specifies that it wants 
$50.00 for rights to read the book, and will provide the book for 
$5.50 if the user agrees to release information about himself. The 
negotiation might go something like this: 



Process A <— > Process B 

Want (right to read, unrestricted) — > 

< — Have(right to read, 
unrestricted, $50) 

Offer (right to read, tender 

user info) — > 

< — Have(right to read, 
tender user info, 
$5.50) 

Accept(right to read, tender 
user info, $5.50) > 



In the above example, process A first specifies that it 
desires the right to read the book without restrictions or other 
information release. This starting position is specified as a rights 
option in the PERC that process A is using as a rule. Process B 
checks its rules and determines that an unrestricted right to read 
is indeed permitted for a price of $50. It replies to process A that 
these terms are available. Process A receives this reply and 
checks it against the control set in the PERC it uses as a rule 
base. The $50 is outside the $10 limit specified for this control 
set, so Process A cannot accept the offer. It makes a counter offer 
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fas described in another optional rights option) of an unrestricted 
right to read coupled with the release of the reader's name and 
address. The name and address fields are described in a DTD 
referenced by Process A's PERC. Process B checks its rules 
PERC and determines that an unrestricted right to read 
combined with the release of personal information is a permitted 
option. It compares the fields that would be released as described 
in the DTD provided by Process A against the desired fields in a 
DTD in its own PERC, and determines an acceptable match has 
occurred. It then sends an offer for unrestricted rights with the 
release of specific information for the cost of $5.50 to Process A. 
Process A compares the right, restrictions, and fields against its 
rule set and determines that $5.50 is within the range of $5-$6 
described as acceptable in its rule set. It accepts the offer as 
made. The offer is sealed by both parties "signing" a new PERC 
that describes the results of the final negotiation (unrestricted 
rights, with release of user information, for $5.50). The new 
PERC may be used by the owner of Process A to read the content 
(the book) subject to the described terms and conditions. 

Further Chain of Handling Model 

As described in connection with Figure 2, there are four (4) 
"participant" instances of VDE 100 in one example of a VDE 
chain of handling and control used, for example, for content 
distribution. The first of these participant instances, the content 
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creator 102, is manipulated by the publisher, author, rights 
owner or distributor of a literary property to prepare the 
information for distribution to the consumer. The second 
participant instance, VDE rights distributor 106, may distribute 
rights and may also administer and analyze customers' use of 
VDE authored information. The third participant instance, 
content user 112, is operated by users (included end-users and 
distributors) when they use information. The fourth participant 
instance, financial clearinghouse 116 enables the VDE related 
clearinghouse activities. A further participant, a VDE 
administrator, may provide support to keep VDE 100 operating 
properly. With appropriate authorizations and Rights Operating 
System components installed, any VDE electronic appliance 600 
can play any or all of these participant roles. 

Literary property is one example of raw material for VDE 
100. To transfer this raw material into finished goods, the 
publisher, author, or rights owner uses tools to transform digital 
information (such as electronic books, databases, computer 
software and movies) into protected digital packages called 
"objects." Only those consumers (or others along the chain of 
possession such as a redistributor) who receive permission from a 
distributor 106 can open these packages. VDE packaged content 
can be constrained by "rules and control information" provided by 
content creator 102 and/or content distributor 106 — or by other 
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VDE participants in the content's distribution pathway, i.e., 
normally by participants "closer" to the creation of the VDE 
secured package than the participant being constrained. 

Once the content is packaged in an "object," the digital 
distribution process may begin. Since the information packages 
themselves are protected, they may be freely distributed on CD- 
ROM disks, through computer networks, or broadcast through 
cable or by airwaves. Informal "out of channel" exchange of 
protected packages among end-users does not pose a risk to the 
content property rights. This is because only authorized 
individuals may use such packages. In fact, such "out of channel" 
distribution may be encouraged by some content providers as a 
marginal cost method of market penetration. Consumers with 
usage authorizations (e.g., a VISA clearinghouse budget allowing 
a certain dollar amount of usage) may, for example, be free to 
license classes of out of channel VDE protected packages 
provided to them, for example, by a neighbor. 

To open a VDE package and make use of its content, an 
end-user must have permission. Distributors 106 can grant these 
permissions, and can very flexibly (if permitted by senior control 
information) limit or otherwise specify the ways in which package 
contents may be used. Distributors 106 and financial 
clearinghouses 116 also typically have financial responsibilities 
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(they may be the same organization in some circumstances if 
desired). They ensure that any payments required from end- 
users fulfill their own and any other participant's requirements. 
This is achieved by auditing usage. 

Distributors 106 using VDE 100 may include software 
publishers, database publishers, cable, television, and radio 
broadcasters, and other distributors of information in electronic 
form. VDE 100 supports all forms of electronic distribution, 
including distribution by broadcast or telecommunications, or by 
the physical transfer of electronic storage media. It also supports 
the delivery of content in homogeneous form, seamlessly 
integrating information from multiple distribution types with 
separate delivery of permissions, control mechanisms and 
content. 

Distributors 106 and financial clearinghouses 116 may 
themselves be audited based on secure records of their 
administrative activities and a chain of reliable, "trusted" 
processes ensures the integrity of the overall digital distribution 
process. This allows content owners, for example, to verify that 
they are receiving appropriate compensation based on actual 
content usage or other agreed-upon bases. 

Since the end-user 112 is the ultimate consumer of content 
in this example, VDE 100 is designed to provide protected 
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content in a seamless and transparent way — so long as the end- 
user stays within the limits of the permissions she has received. 
The activities of end-user 112 can be metered so that an audit 
can be conducted by distributors 106. The auditing process may 
be filtered and/or generalized to satisfy user privacy concerns. 
For example, metered, recorded VDE content and/or appliance 
usage information may be filtered prior to reporting it to 
distributor 106 to prevent more information than necessary from 
being revealed about content user 112 and/or her usage. 

VDE 100 gives content providers the ability to recreate 
important aspects of their traditional distribution strategies in 
electronic form and to innovatively structure new distribution 
mechanisms appropriate to their individual needs and 
circumstances. VDE 100 supports relevant participants in the 
chain of distribution, and also enables their desired pricing 
strategies, access and redistribution permissions, usage rules, 
and related administrative and analysis procedures. The 
reusable functional primitives of VDE 100 can be flexibly 
combined by content providers to reflect their respective 
distribution objectives. As a result, content providers can feed 
their information into established distribution channels and also 
create their own personalized distribution channels. 
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A summary of the roles of the various participants of 
virtual distribution environment 100 is set forth in the table 
below: 



Role 


Description 


"TraditionalTarticipants 


Content creator 


Packager and initial distributor of digital 
information 


Content owner 


Owner of the digital information. 


Distributors 


Provide rights distribution services for budgets 
and/or content. 


xl. 11 LULU I 


Provides services for processing and reducing 
usage based audit trails. 


Clearinghouse 


Provides intermediate store and forward services 
for content and audit information. Also, typically 
provides a platform for other services, including 
third party financial providers and auditors. 


Network provider 


Provides communication services between sites 
and other participants. 


Financial providers 


Provider of third party sources of electronic funds 
to end-users and distributors. Examples of this 
class of users are VISA, American Express, or a 
government. 


End Users 


Consumers of information. 


Other Participants 


Redistributor 


Redistributes rights to use content based on chain 
of handling restrictions from content providers 
and/or other distributors. 


VDE Administrator 


Provider of trusted services for support of VDE 
nodes. 
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Role 


Description 


Independent Audit 


Provider of services for processing and 


Processor 


summarizing audit trail data. Provides anonymity 




to end-users while maintaining the comprehensive 




audit capabilities required by the content 




providers. 


Agents 


Provides distributed presence for end-users and 




other VDE participants. 



Of these various VDE participants, the "redistributor," 
"VDE Administrator," "independent audit processor" and 
"agents" are, in certain respects "new" participants that may 
have no counterpart in many "traditional" business models. The 
other VDE participants (i.e., content provider, content owner, 
distributors, auditor, clearinghouse, network provider and 
financial providers) have "traditional" business model 
counterparts in the sense that traditional distribution models 
often included non-electronic participants performing some of the 
same business roles they serve in the virtual distribution 
environment 100. 

VDE distributors 106 may also include "end-users" who 
provide electronic information to other end-users. For example, 
Figure 77 shows a further example of a virtual distribution 
environment 100 chain of handling and control provided by the 
present invention. As compared to Figure 2, Figure 77 includes a 
new "client administrator" participant 700. In addition, Figure 
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77 shows several different content users 112(1), 112(2), 
112(n) that may all be subject to the "jurisdiction" of the client 
administrator 700. Client administrator 700 may be, for 
example, a further rights distributor within a corporation or 
other organization that distributes rights to employees or other 
organization participant units (such as divisions, departments, 
networks, and or groups, etc.) subject to organization-specific 
"rules and control information." The client administrator 700 
may fashion rules and control information for distribution, 
subject to "rules and control" specified by creator 102 and/or 
distributor 106. 

As mentioned above, VDE administrator 116b is a trusted 
VDE node that supports VDE 100 and keeps it operating 
properly. In this example, VDE administrator 116b may provide, 
among others, any of all of the following: 

• VDE appliance initialization services 

• VDE appliance reinitialization/update services 

• Key management services 

• "Hot lists" of "rogue" VDE sites 

• Certification authority services 

• Public key registration 

• Client participant unit content budgets and other 
authorizations 
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All participants of VDE 100 have the innate ability to 
participate in any role. For example, users may gather together 
existing protected packages, add (create new content) packages of 
their own, and create new products. They may choose to serve as 
their own distributor, or delegate this responsibility to others. 
These capabilities are particularly important in the object 
oriented paradigm which is entering the marketplace today. The 
production of compound objects, object linking and embedding, 
and other multi-source processes will create a need for these 
capabilities of VDE 100. The distribution process provided by 
VDE 100 is symmetrical; any end-user may redistribute 
information received to other end-users, provided they possess 
permission from and follow the rules established by the 
distribution chain VDE control information governing 
redistribution. End-users also may, within the same rules and 
permissions restriction, encapsulate content owned by others 
within newly published works and distribute these works 
independently. Royalty payments for the new works may be 
accessed by the publisher, distributors, or end-users, and may be 
tracked and electronically collected at any stage of the chain. 

Independent financial providers can play an important role 
in VDE 100. The VDE financial provider role is similar to the 
role played by organizations such as VISA in traditional 
distribution scenarios. In any distribution model, authorizing 
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payments for use of products or services and auditing usage for 
consistency and irregularities, is critical. In VDE 100, these are 
the roles filled by independent financial providers. The 
independent financial providers may also provide audit services 
to content providers. Thus, budgets or limits on use, and audits, 
or records of use, may be processed by (and may also be put in 
place by) clearinghouses 116, and the clearinghouses may then 
collect usage payments from users 112. Any VDE user 112 may 
assign the right to process information or perform services on 
their behalf to the extend allowed by senior control information. 
The arrangement by which one VDE participant acts on behalf of 
another is called a "proxy." Audit, distribution, and other 
important rights may be "proxied" if permitted by the content 
provider. One special type of "proxy" is the VDE administrator 
116b. A VDE administrator is an organization (which may be 
acting also as a financial clearinghouse 116) that has permission 
to manage (for example, "intervene" to reset) some portion or all 
of VDE secure subsystem control information for VDE electronic 
appliances. This administration right may extend only to 
admitting new appliances to a VDE infrastructure and to 
recovering "crashed" or otherwise inoperable appliances, and 
providing periodic VDE updates. 



745 



WO 96/27155 



PCT/US96/02303 



More On Object Creation, Distribution Methods, Budgets, and 
Audits 

VDE node electronic appliances 600 in the preferred 
embodiment can have the ability to perform object creation, 
distribution, audit collection and usage control functions provided 
by the present invention. Incorporating this range of capabilities 
within each of many electronic appliances 600 provided by the 
preferred embodiment is important to a general goal of creating a 
single (or prominent) standard for electronic transactions 
metering, control, and billing, that, in its sum of installations, 
constitutes a secure, trusted, virtual transaction/distribution 
management environment. If, generally speaking, certain key 
functions were generally or frequently missing, at least in 
general purpose VDE node electronic appliances 600, then a 
variety of different products and different standards would come 
forth to satisfy the wide range of applications for electronic 
transaction/distribution management; a single consistent set of 
tools and a single "rational," trusted security and commercial 
distribution environment will not have been put in place to 
answer the pressing needs of the evolving "electronic highway." 
Certain forms of certain electronic appliances 600 containing 
VDE nodes which incorporate embedded dedicated VDE 
microcontrollers such as certain forms of video cassette players, 
cable television converters and the like may not necessarily have 
or need full VDE capabilities. However, the preferred 
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embodiment provides a number of distributed, disparately 
located electronic appliances 600 each of which desirably include 
authoring, distribution, extraction, audit, and audit reduction 
capabilities, along with object authoring capabilities. 

The VDE object authoring capabilities provided by the 
preferred embodiment provides an author, for example, with a 
variety of menus for incorporating methods in a VDE object 300, 
including: 

• menus for metering and/or billing methods which 

define how usage of the content portion of a 
VDE object is to be controlled, 

• menus related to extraction methods for limiting 

and/or enabling users of a VDE object from 
extracting information from that object, and 
may include placing such information in a 
newly created and/or pre-existing VDE content 
container,, 

• menus for specifying audit methods — that is, 

whether or not certain audit information is to be 
generated and communicated in some secure 
fashion back to an object provider, object 
creator, administrator, and/or clearinghouse, 
and 
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• menus for distribution methods for controlling 
how an object is distributed, including for 
example, controlling distribution rights of 
different participant's "down" a VDE chain of 
content container handling. 
The authoring capabilities may also include procedures for 
distributing administrative budgets, object distribution control 
keys, and audit control keys to distributors and other VDE 
participants who are authorized to perform distribution and/or 
auditing functions on behalf of the author, distributors, and/or 
themselves. The authoring capabilities may also include 
procedures for selecting and distributing distribution methods, 
audit methods and audit reduction methods, including for 
example, securely writing and/or otherwise controlling budgets 
for object redistribution by distributors to subsequent VDE chain 
of content handling participants. 

The content of an object 300 created by an author may be 
generated with the assistance of a VDE aware application 
program or a non-VDE aware application program. The content 
of the object created by an author in conjunction with such 
programs may include text, formatted text, pictures, moving 
pictures, sounds, computer software, multimedia, electronic 
games, electronic training materials, various types of files, and so 
on, without limitation. The authoring process may encapsulate 
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content generated by the author in an object, encrypt the content 
with one or more keys, and append one or more methods to define 
parameters of allowed use and/or required auditing of use and/or 
payment for use of the object by users (and/or by authorized users 
only). The authoring process may also include some or all aspects 
of distributing the object. 

In general, in the preferred embodiment, an author can: 

A. Specify what content is to be included in an 

object. 

B. Specify content oriented methods including: 

Information-typically abstract, promotional, 
identifying, scheduling, and/or other 
information related to the content and/or 
author 

Content-e.g. list of files and/or other 
information resources containing content, time 
variables, etc. 

C. Specify control information (typically a collection 

of methods related to one another by one or 
more permissions records, including any method 
defining variables) and any initial authorized 
user list including, for example: 
Control information over Access & Extraction 
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Control information over Distribution 
Control information over Audit Processing 

A VDE node electronic appliance 600 may, for example, 
distribute an object on behalf of an object provider if a VDE node 
receives from an object provider administrative budget 
information for distributing the object and associated distribution 
key information. 

A VDE node electronic appliance 600 may receive and 
process audit records on behalf of an object provider if that VDE 
node receives any necessary administrative budget, audit 
method, and audit key information (used, for example, to decrypt 
audit trails), from the object provider. An auditing-capable VDE 
electronic appliance 600 may control execution of audit reduction 
methods. "Audit reduction" in the preferred embodiment is the 
process of extracting information from audit records and/or 
processes that an object provider (e.g., any object provider along a 
chain of handling of the object) has specified to be reported to an 
object's distributors, object creators, client administrators, and/or 
any other user of audit information. This may include, for 
example, advertisers who may be required to pay for a user's 
usage of object content. In one embodiment, for example, a 
clearinghouse can have the ability to "append" budget, audit 
method, and/or audit key information to an object or class or 
other grouping of objects located at a user site or located at an 
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object provider site to ensure that desired audit processes will 
take place in a "trusted" fashion. A participant in a chain of 
handling of a VDE content container and/or content container 
control information object may act as a "proxy" for another party 
in a chain of handling of usage auditing information related to 
usage of object content (for example a clearinghouse, an 
advertiser, or a party interested in market survey and/or specific 
customer usage information). This may be done by specifying, for 
that other party, budget, audit method, and/or key information 
that may be necessary to ensure audit information is gathered 
and/or provided to, in a proper manner, said additional party. 
For example, employing specification information provided by 
said other party. 

Object Creation and Initial Control Structures 

The VDE preferred embodiment object creation and control 
structure design processes support fundamental configurability 
of control information. This enables VDE 100 to support a full 
range of possible content types, distribution pathways, usage 
control information, auditing requirements, and users and user 
groups. VDE object creation in the preferred embodiment 
employs VDE templates whose atomic elements represent at 
least in part modular control processes. Employing VDE creation 
software (in the preferred embodiment a GUI programming 
process) and VDE templates, users may create VDE objects 300 
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by, for example, partitioning the objects, placing "meta data" 
(e.g., author's name, creation date, etc.) into them, and assigning 
rights associated with them and/or object content to, for example, 
a publisher and/or content creator. When an object creator runs 
through this process, she normally will go through a content 
specification procedure which will request required data. The 
content specification process, when satisfied, may proceed by, for 
example, inserting data into a template and encapsulating the 
content. In addition, in the preferred embodiment, an object may 
also automatically register its presence with the local VDE node 
electronic appliance 600 secure subsystem, and at least one 
permissions record 808 may be produced as a result of the 
interaction of template instructions and atomic methods, as well 
as one or more pieces of control structure which can include one 
or more methods, budgets, and/or etc. A registration process may 
require a budget to be created for the object. If an object creation 
process specifies an initial distribution, an administrative object 
may also be created for distribution. The administrative object 
may contain one or more permission records 808, other control 
structures, methods, and/or load modules. 

Permissions records 808 may specify various control 
relationships between objects and users. For example, VDE 100 
supports both single access (e.g., one-to-one relationship between 
a user and a right user) and group access (any number of people 
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may be authorized as a group). A single permissions record 808 
can define both single and group access. VDE 100 may provide 
"sharing," a process that allows multiple users to share a single 
control budget as a budget. Additional control structure concepts 
include distribution, redistribution, and audit, the latter 
supporting meter and budget information reduction and/or 
transfer. All of these processes are normally securely controlled 
by one or more VDE secure subsystems. 

Templates and Classes 

VDE templates, classes, and flexible control structures 
support frameworks for organizations and individuals that 
create, modify, market, distribute, redistribute, consume, and 
otherwise use movies, audio recordings and live performances, 
magazines, telephony based retail sales, catalogs, computer 
software, information databases, multimedia, commercial 
communications, advertisements, market surveys, infomercials, 
games, CAD/CAM services for numerically controlled machines, 
and the like. As the context surrounding these classes changes 
or evolves, the templates provided by the preferred embodiment 
of the present invention can be modified to meet these changes 
for broad use, or more focused activities. 

VDE 100 authoring may provide three inputs into a create 
process: Templates, user input and object content. Templates 
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act as a set of control instructions and/or data for object control 
software which are capable of creating (and/or modifying) VDE 
objects in a process that interacts with user instructions and 
provided content to create a VDE object. Templates are usually 
specifically associated with object creation and/or control 
structures. Classes represent user groups which can include 
"natural" groups within an organization, such as department 
members, specific security clearance levels, etc., or ad hoc lists of 
individual's and/or VDE nodes. 

For example, templates may be represented as text files 
defining specific structures and/or component assemblies. 
Templates, with their structures and/or component assemblies 
may serve as VDE object authoring or object control applications. 
A creation template may consist of a number of sub-templates, 
which, at the lowest level, represent an "atomic level" of 
description of object specification. Templates may present one or 
more models that describe various aspects of a content object and 
how the object should be created including employing secure 
atomic methods that are used to create, alter, and/or destroy 
permissions records 808 and/or associated budgets, etc. 

Templates, classes (including user groups employing an 
object under group access), and flexible control structures 
including object "independent" permissions records (permissions 
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that can be associated with a plurality of objects) and structures 
that support budgeting and auditing as separate VDE processes, 
help focus the flexible and configurable capabilities inherent 
within authoring provided by the present invention in the context 
of specific industries and/or businesses and/or applications. VDE 
rationalizes and encompasses distribution scenarios currently 
employed in a wide array of powerful industries (in part through 
the use of application or industry specific templates). Therefore, 
it is important to provide a framework of operation and/or 
structure to allow existing industries and/or applications and/or 
businesses to manipulate familiar concepts related to content 
types, distribution approaches, pricing mechanisms, user 
interactions with content and/or related administrative activities, 
budgets, and the like. 

The VDE templates, classes, and control structures are 
inherently flexible and configurable to reflect the breadth of 
information distribution and secure storage requirements, to 
allow for efficient adaptation into new industries as they evolve, 
and to reflect the evolution and/or change of an existing industry 
and/or business, as well as to support one or more groups of users 
who may be associated with certain permissions and/or budgets 
and object types. The flexibility of VDE templates, classes, and 
basic control structures is enhanced through the use of VDE 
aggregate and control methods which have a compound, 
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conditional process impact on object control. Taken together, and 
employed at times with VDE administrative objects and VDE 
security arrangements and processes, the present invention truly 
achieves a content control and auditing architecture that can be 
configured to most any commercial distribution embodiment. 
Thus, the present invention fully supports the requirements and 
biases of content providers without forcing them to fit a 
predefined application model It allows them to define the rights, 
control information, and flow of their content (and the return of 
audit information) through distribution channels. 

Modifying Object Content (Adding, Hiding, Modifying, Removing, 
and/or Extending) 

Adding new content to objects is an important aspect of 
authoring provided by the present invention. Providers may 
wish to allow one-or more users to add, hide, modify, remove 
and/or extend content that they provide. In this way, other users 
may add value to, alter for a new purpose, maintain, and/or 
otherwise change, existing content. The ability to add content to 
an empty and/or newly created object is important as well. 

When a provider provides content and accompanying 
control information, she may elect to add control information that 
enables and/or limits the addition, modification, hiding and/or 
deletion of said content. This control information may concern: 
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• the nature and/or location of content that may be 

added, hidden, modified, and/or deleted; 

• portions of content that may be modified, hidden, 

deleted and/or added to; 

• required secure control information over 

subsequent VDE container content usage in a 
chain of control and/or locally to added, hidden, 
and/or modified content; 

• requirements that provider-specified notices 

and/or portions of content accompany added, 
hidden, deleted and/or modified content and/or 
the fact that said adding, hiding, modification 
and/or deletion occurred; 

• secure management of limitations and/or 

requirements concerning content that may be 
removed, hidden and/or deleted from content, 
including the amount and/or degree of addition, 
hiding, modification and/or deletion of content; 

• providing notice to a provider or providers that 

modification, hiding, addition and/or deletion 
has occurred and/or the nature of said 
occurrence; and 

• other control information concerned with 

modification, addition, hiding, and/or deleting 
provider content. 
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A provider may use this control information to establish an 
opportunity for other users to add value to and/or maintain 
existing content in a controlled way. For example, a provider of 
software development tools may allow other users to add 
commentary and/or similar and/or complementary tools to their 
provided objects. A provider of movies may allow commentary 
and/or promotional materials to be added to their materials. A 
provider of CAD/CAM specifications to machine tool owners may 
allow other users to modify objects containing instructions 
associated with a specification to improve and/or translate said 
instructions for use with their equipment. A database owner 
may allow other users to add and/or remove records from a 
provided database object to allow flexibility and/or maintenance 
of the database. 

Another benefit of introducing control information is the 
opportunity for a provider to allow other users to alter content for 
a new purpose. A provider may allow other users to provide 
content in a new setting. 

To attach this control information to content, a provider 
may be provided with, or if allowed, design and implement, a 
method or methods for an object that govern addition, hiding, 
modification and/or deletion of content. Design and 
implementation of such one or more methods may be performed 
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using VDE software tools in combination with a PPE 650. The 
provider may then attach the method(s) to an object and/or 
provide them separately. A permissions record 808 may include 
requirements associated with this control information in 
combination with other control information, or a separate 
permissions record 808 may be used. 

An important aspect of adding or modifying content is the 
choice of encryption/decryption keys and/or other relevant 
aspects of securing new or altered content. The provider may 
specify in their method(s) associated with these processes a 
technique or techniques to be used for creating and/or selecting 
the encryption/decryption keys and/or other relevant aspect of 
securing new and/or altered content. For example, the provider 
may include a collection of keys, a technique for generating new 
keys, a reference to a load module that will generate keys, a 
protocol for securing content, and/or other similar information. 

Another important implication is the management of new 
keys, if any are created and/or used. A provider may require that 
such keys and reference to which keys were used must be 
transmitted to the provider, or she may allow the keys and/or 
securing strategy to remain outside a provider's knowledge 
and/or control. A provider may also choose an intermediate 
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course in which some keys must be transmitted and others may 
remain outside her knowledge and/or control. 

An additional aspect related to the management of keys is 
the management of permissions associated with an object 
resulting from the addition, hiding, modification and/or deletion 
of content. A provider may or may not allow a VDE chain of 
control information user to take some or all of the VDE rules and 
control information associated with granting permissions to 
access and/or manipulate VDE managed content and/or rules and 
control information associated with said resulting object. For 
example, a provider may allow a first user to control access to 
new content in an object, thereby requiring any other user of that 
portion of content to receive permission from the first user. This 
may or may not, at the provider's discretion, obviate the need for 
a user to obtain permission from the provider to access the object 
at all. 

Keys associated with addition, modification, hiding and/or 
deletion may be stored in an independent permissions record or 
records 808. Said permissions record(s) 808 may be delivered to a 
provider or providers and potentially merged with an existing 
permissions record or records, or may remain solely under the 
control of the new content provider. The creation and content of 
an initial permissions record 808 and any control information 
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over the permissions record(s) are controlled by the method(s) 
associated with activities by a provider. Subsequent modification 
and/or use of said permission record(s) may involve a provider's 
method(s), user action, or both. A user's ability to modify and/or 
use permissions record(s) 808 is dependent on, at least in part, 
the senior control information associated with the permissions 
record(s) of a provider. 

Distribution Control information 

To enable a broad and flexible commercial transaction 
environment, providers should have the ability to establish firm 
control information over a distribution process without unduly 
limiting the possibilities of subsequent parties in a chain of 
control. The distribution control information provided by the 
present invention allow flexible positive control. No provider is 
required to include any particular control, or use any particular 
strategy, except as required by senior control information. 
Rather, the present invention allows a provider to select from 
generic control components (which may be provided as a subset of 
components appropriate to a provider's specific market, for 
example, as included in and/or directly compatible with, a VDE 
application) to establish a structure appropriate for a given chain 
of handling/control. A provider may also establish control 
information on their control information that enable and limit 
modifications to their control information by other users. 
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The administrative systems provided by the present 
invention generate administrative "events." These "e vents" 
correspond to activities initiated by either the system or a user 
that correspond to potentially protected processes within VDE. 
These processes include activities such as copying a permissions 
record, copying a budget, reading an audit trail record, copying a 
method, updating a budget, updating a permissions record, 
updating a method, backing up management files, restoring 
management files, and the like. Reading, writing, modifying, 
updating, processing, and/or deleting information from any 
portion of any VDE record may be administrative events. An 
administrative event may represent a process that performs one 
or more of the aforementioned activities on one or more portions 
of one or more records. 

When a VDE electronic appliance 600 encounters an 
administrative event, that event is typically processed in 
conjunction with a VDE PPE 650. As in the case of events 
generally related to access and/or use of content, in most cases 
administrative events are specified by content providers 
(including, for example, content creators, distributors, and/or 
client administrators) as an aspect of a control specified for an 
object, group and/or class of objects. 
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For example, if a user initiates a request to distribute 
permission to use a certain object from a desktop computer to a 
notebook computer, one of the administrative events generated 
may be to create a copy of a permissions record that corresponds 
to the object. When this administrative event is detected by ROS 
602, an EVENT method for this type of event may be present. If 
an EVENT method is present, there may also be a meter, a 
billing, and a budget associated with the EVENT method. 
Metering, billing, and budgeting can allow a provider to enable 
and limit the copying of a permissions record 808. 

For example, during the course of processing a control 
program, a meter, a billing, and a budget and/or audit records 
may be generated and/or updated. Said audit records may record 
information concerning circumstances surrounding an 
administrative event and processing of said event. For example, 
an audit record may contain a reference to a user and/or system 
activity that initiated an event, the success or failure of 
processing said event, the date and/or time, and/or other relevant 
information. 

Referring to the above example of a user with both a 
desktop and notebook computer, the provider of a permissions 
record may require an audit record each time a meter for copying 
said permissions record is processed. The audit record provides a 
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flexible and configurable control and/or recording environment 
option for a provider. 

In some circumstances, it may be desirable for a provider 
to limit which aspects of a control component may be modified, 
updated, and/or deleted. "Atomic element definitions" may be 
used to limit the applicability of events (and therefore the 
remainder of a control process, if one exists) to certain "atomic 
elements" of a control component. For example, if a permissions 
record 808 is decomposed into "atomic elements" on the fields 
described in Figure 26, an event processing chain may be limit ed, 
for example, to a certain number of modifications of expiration 
date/time information by specifying only this field in an atomic 
element definition. In another example, a permissions record 808 
may be decomposed into atomic elements based on control sets. 
In this example, an event chain may be limited to events that act 
upon certain control sets. 

In some circumstances, it may be desirable for a provider 
to control how administrative processes are performed. The 
provider may choose to include in distribution records stored in 
secure database 610 information for use in conjunction with a 
component assembly 690 that controls and specifies, for example, 
how processing for a given event in relation to a given method 
and/or record should be performed. For example, if a provider 
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wishes to allow a user to make copies of a permissions record 808, 
she may want to alter the permissions record internally. For 
example, in the earlier example of a user with a desktop and a 
notebook computer, a provider may allow a user to make copies of 
information necessary to enable the notebook computer based on 
information present in the desktop computer, but not allow any 
farther copies of said information to be made by the notebook 
VDE node. In this example, the distribution control structure 
described earlier would continue to exist on the desktop 
computer, but the copies of the enabling information passed to 
the notebook computer would lack the required distribution 
control structure to perform distribution from the notebook 
computer. Similarly, a distribution control structure may be 
provided by a content provider to a content provider who is a 
distributor in which a control structure would enable a certain 
number of copies to be made of a VDE content container object 
along with associated copies of permissions records, but the 
permissions records would be altered (as per specification of the 
content provider, for example) so as not to allow end-users who 
received distributor created copies from making further copies for 
distribution to other VDE nodes. 

Although the preceding example focuses on one particular 
event (copying) under one possible case, similar processes may be 
used for reading, writing, modifying, updating, processing, 
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and/or deleting information from records and/or methods under 
any control relationship contemplated by the present invention. 
Other examples include: copying a budget, copying a meter, 
updating a budget, updating a meter, condensing an audit trail, 
and the like. 

Creating Custom Methods 

In the preferred embodiment of the present invention, 
methods may be created "at will," or aliased to another method. 
These two modes contribute to the superior configurability, 
flexibility, and positive control of the VDE distribution process. 
Generally, creating a method involves specifying the required 
attributes or parameters for the data portion of the method, and 
then "typing" the method. The typing process typically involves 
choosing one or more load modules to process any data portions of 
a method. In addition to the method itself, the process of method 
creation may also result in a method option subrecord for 
inclusion in, or modification of, a permissions record, and a 
notation in the distribution records. In addition to any 
"standard" load module(s) required for exercise of the method, 
additional load modules, and data for use with those load 
modules, may be specified if allowed. These event processing 
structures control the distribution of the method. 
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For example, consider the case of a security budget. One 
form of a typical budget might limit the user to 10Mb of 
decrypted data per month. The user wishes to move their rights 
to vise the relevant VDE content container object to their 
notebook. The budget creator might have limited the notebook to 
the same amount, half the original amount, a prorated amount 
based on the number of moves budgeted for an object, etc. A 
distribute method (or internal event processing structure) 
associated with the budget allows the creator of the budget to 
make a determination as to the methodology and parameters 
involved. Of course, different distribution methods may be 
required for the case of redistribution, or formal distribution of 
the method. The aggregate of these choices is stored in a 
permissions record for the method. 

An example of the process steps used for the move of a 
budget record might look something like this: 

1) Check the move budget (e.g., to determine the 

number of moves allowed) 

2) Copy static fields to new record (e.g., as an 
encumbrance) 

3) Decrement the Deer counter in the old record (the 

original budget) 

4) Increment the Encumbrance counter in the old 

record 
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5) Write a distribution record 

6) Write a Distribution Event Id to the new record 

7) Increment the move meter 

8) Decrement the move budget 

9) Increment the Deer counter in the new record 



Creating a Budget 

In the preferred embodiment, to create a budget, a user 
manipulates a Graphical User Interface budget distribution 
application (e.g., a VDE template application). The user fills out 
any required fields for type(s) of budget, expiration cycle(s), 
auditor(s), etc. A budget may be specified in dollars, deutsche 
marks, yen, and/or in any other monetary or content 
measurement schema and/or organization. The prefenred 
embodiment output of the application, normally has three basic 
elements. A notation in the distribution portion of secure 
database 610 for each budget record created, the actual budget 
records, and a method option record for inclusion in a 
permissions record. Under some circumstances, a budget process 
may not result in the creation of a method option since an 
existing method option may be being used. Normally, all of this 
output is protected by storage in secure database 610 and/or in 
one or more administrative objects. 
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There are two basic modes of operation for a budget 
distribution application in the preferred embodiment. In the first 
case, Hie operator has an unlimited ability to specify budgets. 
The budgets resulting from this type of activity may be freely 
used to control any aspect of a distribution process for which an 
operator has rights, including for use with "security" budgets 
such as quantities limiting some aspect of usage. For example, if 
the operator is a "regular person," he may use these budgets to 
control his own utilization of objects based on a personal 
accounting model or schedule. If the operator is an authorized 
user at VISA, the resulting budgets may have broad implications 
for an entire distribution system. A core idea is that this mode is 
controlled strictly by an operator. 

The second mode of operation is used to create "alias" 
budgets. These budgets are coupled to a preexisting budget in an 
operator's system. When an operator fills a budget, an 
encumbrance is created on the aliased budget. When these types 
of budgets are created, the output includes two method option 
subrecords coupled together: the method option subrecord for the 
aliased budget, and a method option subrecord for the newly 
created budget. In most cases, the alias budget can be used in 
place of the original budget if the budget creator is authorized to 
modify the method options within the appropriate required 
method record of a permissions record. 
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For example, assume that a user (client administrator) at a 
company has the company's VISA budget on her electronic 
appliance 600. She wants to distribute budget to a network of 
company users with a variety of preexisting budgets and 
requirements. She also wants to limit use of the company's VISA 
budget to certain objects. To do this, she aliases a company 
budget to the VISA budget. She then modifies (if so authorized) 
the permissions record for all objects that the company will allow 
their users to manipulate so that they recognize the company 
budget in addition to, or instead of, the VISA budget. She then 
distributes the new permissions records and budgets to her users. 
The audit data from these users is then reduced against the 
encumbrance on the company's VISA budget to produce a 
periodic billing. 

In another example, a consumer wants to control his 
family's electronic appliance use of his VISA card, and prevent 
his children from playing too many video games, while allowing 
unlimited use of encyclopedias. In this case, he could create two 
budgets. The first budget can be aliased to his VISA card, and 
might only be used with encyclopedia objects (referenced to 
individual encyclopedia objects and/or to one or more classes of 
encyclopedia objects) that reference the aliased budget in their 
explicitly modified permissions record. The second budget could 
be. for example, a time budget that he redistributes to the family 
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for use with video game objects (video game class). In this 
instance, the second budget is a "self-replenishing" 
security/control budget, that allows, for example, two hours of use 
per day. The first budget operates in the same maimer as the 
earlier example. The second budget is added as a new required 
method to permissions records for video games. Since the time 
budget is required to access the video games, an effective control 
path is introduced for requiring the second budget - only 
permissions records modified to accept the family budget can be 
used by the children for video games and they are limited to two 
hours per day. 

Sharing and Distributing Rights and Budgets 
Move 

The VDE "move" concept provided by the preferred 
embodiment covers the case of "friendly sharing" of rights and 
budgets. A typical case of "move" is a user who owns several 
machines and wishes to use the same objects on more than one of 
them. For example, a user owns a desktop and a notebook 
computer. They have a subscription to an electronic newspaper 
that they wish to read on either machine, i.e., the user wishes to 
move rights from one machine to the other. 

An important concept within "move" is the idea of 
independent operation. Any electronic appliance 600 to which 
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rights have been moved may contact distributors or 
clearinghouses independently. For example, the user mentioned 
above may want to take their notebook on the road for an 
extended period of time, and contact clearinghouses and 
distributors without a local connection to their desktop. 

To support independent operation, the user should be able 
to define an account with a distributor or clearinghouse that is 
independent of the electronic appliance 600 she is using to 
connect. The transactions must be independently traceable and 
reconcilable among and between machines for both the end user 
and the clearinghouse or distributor. The basic operations of 
moving rights, budgets, and bitmap or compound meters between 
machines is also supported. 

Redistribution 

Redistribution forms a UDE middle ground between the 
"friendly sharing" of "move," and formal distribution. 
Redistribution can be thought of as "anonymous distribution" in 
the sense that no special interaction is required between a 
creator, clearinghouse, or distributor and a redistributor. Of 
course, a creator or distributor does have the ability to limit or 
prevent redistribution. 
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Unlike the "move" concept, redistribution does not imply 
independent operation. The redistributor serves as one point of 
contact for users receiving redistributed rights and/or budgets, 
etc. These users have no knowledge of, or access to, the 
clearinghouse (or and/or distributor) accounts of the 
redistributor. The redistributor serves as an auditor for the 
rights and/or budgets, etc. that they redistribute, unless 
specifically overridden by restrictions from distributors and/or 
clearinghouses. Since redistributees (recipients of redistributed 
rights and/or budgets, etc.) would place a relatively 
unquantifiable workload on clearinghouses, and furthermore, 
since a redistributor would be placing himself at an auditable 
risk (responsible for all redistributed rights and/or budgets, etc.), 
the audit of rights, budgets, etc. of redistributees by 
redistributors is assumed as the default case in the preferred 
embodiment. 

Distribution 

Distribution involves three types of entity. Creators 
usually are the source of distribution. They typically set the 
control structure "context" and can control the rights which are 
passed into a distribution network. Distributors are users who 
form a link between object (content) end users and object 
(content) creators. They can provide a two-way conduit for rights 
and audit data. Clearinghouses may provide independent 
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financial services, such as credit and/or billing services, and can 
serve as distributors and/or creators. Through a permissions and 
budgeting process, these parties collectively can establish fine 
control over the type and extent of rights usage and/or auditing 
activities. 

Encumbrance 

An "encumbrance" is a special type of VDE budget. When 
that a budget distribution of any type occurs, an "encumbrance" 
may be generated. An encumbrance is indistinguishable from an 
original budget for right exercise (e.g., content usage payment) 
purposes, but is uniquely identified within distribution records as 
to the amount of the encumbrance, and all necessary information 
to complete a shipping record to track the whereabouts of an 
encumbrance. For right exercise purposes, an encumbrance is 
identical to an original budget; but for tracking purposes, it is 
uniquely identifiable. 

In the preferred embodiment of the present invention, a 
Distribution Event ID will be used by user VDE nodes and by 
clearinghouse services to track and reconcile encumbrances, even 
in the case of asynchronous audits. That is, the "new" 
encumbrance budget is unique from a tracking point of view, but 
indistinguishable from a usage point of view. 
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Unresolved encumbrances are a good intermediate control 
for a VDE distribution process. A suitable "grace period" can be 
introduced during which encumbrances must be resolved. If this 
period elapses, an actual billing or payment may occur. However, 
even after the interval has expired and the billing and/or 
payment made, an encumbrance may still be outstanding and 
support later reconciliation. In this case, an auditor may allow a 
user to gain a credit, or a user may connect to a VDE node 
containing an encumbered budget, and resolve an amount as an 
internal credit. In some cases, missing audit trails may concern a 
distributor sufficiently to revoke redistribution privileges if 
encumbrances are not resolved within a "grace period," or if there 
are repeated grace period violations or if unresolved 
encumbrances are excessively large. 

Encumbrances can be used across a wide variety of 
distribution modes. Encumbrances, when used in concert with 
aliasing of budgets, opens important additional distribution 
possibilities. In the case of aliasing a budget, the user places 
himself in the control path for an object - an aliased budget may 
only be used in conjunction with permissions records that have 
been modified to recognize it. An encumbrance has no such 
restrictions. 
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For example, a user may want to restrict his children's vise 
of his electronic, VDE node VISA budget. In this case, the user 
can generate an encumbrance on his VISA budget for the 
children's family alias budget, and another for his wife that is a 
transparent encumbrance of the original VISA budget. BigCo 
may use a similar mechanism to distribute VISA budget to 
department heads, and aliased BigCo budget to users directly. 

Account Numbers and User IDs 

In the preferred embodiment, to control access to 
clearinghouses, users are assigned account numbers at 
clearinghouses. Account numbers provide a unique "instance" 
value for a secure database record from the point of view of an 
outsider. From the point of view of an electronic appliance 600 
site, the user, group, or group/user ids provide the unique 
instance of a record. For example, from the point of view of VISA, 
your Gold Card belongs to account number #123456789. From 
the point of view of the electronic appliance site (for example, a 
server at a corporation), the Gold card might belong to user id 
1023. In organizations which have plural users and/or user 
groups using a VDE node, such users and/or user groups will 
likely be assigned unique user IDs. differing budgets and/or 
other user rights may be assigned to different users and/or user 
groups and/or other VDE control information may be applied on a 
differing manner to electronic content and/or appliance usage by 
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users assigned with different such IDs. Of course, both a 
clearinghouse and a local site will likely have both pieces of 
information, but "used data" versus the "comment data" may 
differ based on perspective. 

In the preferred embodiment case of "move," an account 
number stored with rights stays the same. In the preferred 
embodiment of other forms of distribution, a new account number 
is required for a distributee. This may be generated 
automatically by the system, or correspond to a methodology 
developed by a distributor or redistributor. Distributors 
maintain account numbers (and associated access secrets) in 
their local name services for each distributee. Conversely, 
distributees' name services may store account numbers based on 
user id for each distributor. This record usually is moved with 
other records in the case of move, or is generated during other 
forms of distribution. 

Organizations (including families) may automatically 
assign unique user IDs when creating control information (e.g., a 
budget) for a new user or user group. 

Requirements Record 

In order to establish the requirements, and potentially 
options, for exercising a right associated with a VDE content 
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container object before one or more required permissions records 
are received for that object, a requirements record may exist in 
the private header of such an object. This record will help the 
user establish what they have, and what they need from a 
distributor prior to forming a connection. If the requirements or 
possibilities for exercising a particular right have changed since 
such an object was published, a modified requirements record 
may be included in a container with an object (if available and 
allowed), or a new requirements record may be requested from a 
distributor before registration is initiated. Distributors may 
maintain "catalogs" online, and/or delivered to users, of 
collections of requirements records and/or descriptive information 
corresponding to objects for which they may have ability to obtain 
and/or grant rights to other users. 

Passing an Audit 

In the preferred embodiment of VDE there may be at least 
two types of auditing. In the case of budget distribution, billing 
records that reflect consumption of a budget generally need to be 
collected and processed. In the case of permissions distribution, 
usage data associated with an object are also frequently required. 

In order to effect control over an object, a creator may 
establish the basic control information associated with an object. 
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This is done in the formulation of permissions, the distribution of 
various security, administrative and/or financial budgets, and the 
level of redistribution that is allowed, etc. Distributors (and 
redistributors) may farther control this process within the rights, 
budgets, etc. (senior control information) they have received. 

For example, an object creator may specify that additional 
required methods may be added freely to their permissions 
records, establish no budget for this activity, and allow unlimited 
redistribution of this right. As an alternative example, a creator 
may allow moving of usage rights by a distributor to half a dozen 
subdistributors, each of whom can distribute 10,000 copies, but 
with no redistribution rights being allowed to be allocated to 
subdistributors' (redistributors*) customers. As another example, 
a creator may authorize the moving of usage rights to only 10 
VDE nodes, and to only one level of distribution (no 
redistribution). Content providers and other contributors of 
control information have the ability through the use of 
permissions records and/or component assemblies to control 
rights other users are authorized to delegate in the permissions 
records they send to those users, so long as such right to control 
one, some, or all such rights of other users is either permitted or 
restricted (depending on the control information distribution 
model). It is possible and often desirable, using VDE, to 
construct a mixed model in which a distributor is restricted from 
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controlling certain rights of subsequent users and is allowed to 
control other rights. VDE control of rights distribution in some 
VDE models will in part or whole, at least for certain one or more 
"levels" of a distribution chain, be controlled by electronic content 
control information providers who are either not also providers of 
the related content or provide only a portion of the content 
controlled by said content control information, for example, in 
certain models, a clearinghouse might also serve as a rights 
distribution agent who provides one or more rights to certain 
value chain participants, which one or more rights may be 
"attached" to one or more rights to use the clearinghouse's credit 
(if said clearinghouse is, at least in part, a financial 
clearinghouse (such a control information provider may 
alternatively, or in addition, restrict other users' rights. 

A content creator or other content control information 
provider may budget a user (such as a distributor) to create an 
unlimited number of permissions records for a content object, but 
revoke this right and/or other important usage rights through an 
expiration/termination process if the user does not report his 
usage (provide an audit report) at some expected one or more 
points in time and/or after a certain interval of time (and/or if the 
user fails to pay for his usage or violates other aspects of the 
agreement between the user and the content provider). This 
termination (or suspension or other specified consequence) can be 
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enforced, for example, by the expiration of time-aged encryption 
keys which were employed to encrypt one or more aspects of 
control information. This same termination (or other specified 
consequence such as budget reduction, price increase, message 
displays on screen to users, messages to administrators, etc.) can 
also be the consequence of the failure by a user or the users VDE 
installation to complete a monitored process, such as paying for 
usage in electronic currency, failure to perform backups of 
important stored information (e.g., content and/or appliance 
usage information, control information, etc.), failure to use a 
repeated failure to use the proper passwords or other identifiers, 
etc.). 

Generally, the collection of audit information that is 
collected for reporting to a certain auditor can be enforced by 
expiration and/or other termination processes. For example, the 
user's VDE node may be instructed (a) from an external source to 
no longer perform certain tasks, (b) carries within its control 
structure information informing it to no longer perform certain 
tasks, or (c) is elsewise no longer able to perform certain tasks. 
The certain tasks might comprise one or more enabling 
operations due to a user's (or installation's) failure to either 
report said audit information to said auditor and/or receive back 
a secure confirmation of receipt and/or acceptance of said audit 
information. If an auditor fails to receive audit information from 
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a user (or some other event fails to occur or occur properly), one 
or more time-aged keys which are used, for example, as a security 
component of an embodiment of the present invention, may have 
their aging suddenly accelerated (completed) so that one or more 
processes related to said time-aged keys can no longer be 
performed. 

Authorization Access Tags and Modification Access Tags 

In order to enable a user VDE installation to pass audit 
information to a VDE auditing party such as a Clearinghouse, 
VDE allows a VDE auditing party to securely, electronically 
communicate with the user VDE installation and to query said 
installation for certain or all information stored within said 
installation's secure sub-system, depending on said auditing 
party's rights (said party shall normally be unable to access 
securely stored information that said party is not expressly 
authorized to access, that is one content provider will normally 
not be authorized to access content usage information related to 
content provided by a different content provider). The auditing 
party asserts a secure secret (e.g., a secure tag) that represents 
the set of rights of the auditor to access certain information 
maintained by said subsystem. If said subsystem validates said 
tag, the auditing party may then* receive auditing information 
that it is allowed to request and receive. 
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Great flexibility exists in the enforcement of audit trail 
requirements. For example, a creator (or other content provider 
or control information provider or auditor in an object's or audit 
report's chain of handling) may allow changes by an auditor for 
event trails, but not allow anyone but themselves to read those 
trails, and limit the redistribution of this right to, for example, six 
levels. Alternatively, a creator or other controlling party may 
give a distributor the right to process, for example, 100,000 audit 
records (and/or, for example, the right to process 12 audit records 
from a given user) before reporting their usage. If a creator or 
other controlling party desires, he may allow (and/or require) 
separate (and containing different, a subset of, overlapping, or 
the same information) audit "packets" containing audit 
information, certain of said audit information to be processed by 
a distributor and certain other of said audit information to be 
passed back to the creator and/or other auditors (each receiving 
the same, overlapping, a subset of, or different audit 
information). Similarly, as long as allowed by, for example, an 
object creator, a distributor (or other content and/or control 
information provider) may require audit information to be passed 
back to it, for example, after every 50,000 audit records are 
processed (or any other unit of quantity and/or after a certain 
time interval and/or at a certain predetermined date) by a 
redistributor. In the preferred embodiment, audit rules, like 
other control structures, may be stipulated at any stage of a 
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distribution chain of handling as long as the right to stipulate 
said rules has not been restricted by a more "senior" object and/or 
control information distributing (such as an auditing) 
participant. 

Audit information that is destined for different auditors 
may be encrypted by different one or more encryption keys which 
have been securely provided by each auditor's VDE node and 
communicated for inclusion in a user's permissions record(s) as a 
required step, for example, during object registration. This can 
provide additional security to further ensure (beyond the use of 
passwords and/or other identification information and other VDE 
security features) that an auditor may only access audit 
information to which he is authorized. In one embodiment, 
encrypted (and/or unencrypted) "packets" of audit information 
(for example, in the form of administrative objects) may be bound 
for different auditors including a clearinghouse and/or content 
providers and/or other audit information users (including, for 
example, market analysts and/or list purveyors). The 
information may pass successively through a single chain of 
handling, for example, user to clearinghouse to redistributor to 
distributor to publisher/object creator, as specified by VDE audit 
control structures and parameters. Alternatively, encrypted (or, 
normally less preferably, unencrypted) audit packets may be 
required to be dispersed directly from a user to a plurality of 
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auditors, some one or more who may have the responsibility to 
"pass along" audit packets to other auditors. In another 
embodiment, audit information may be passed, for example, to a 
clearinghouse, which may then redistribute all and/or 
appropriate subsets of said information (and/or some processed 
result) to one or more other parties, said redistribution employing 
VDE secure objects created by said clearinghouse. 

An important function of an auditor (receiver of audit 
information) is to pass administrative events back to a user VDE 
node in acknowledgement that audit information has been 
received and/or "recognized." In the preferred embodiment, the 
receipt and/or acceptance of audit information may be followed by 
two processes. The first event will cause the audit data at a VDE 
node which prepared an audit report to be deleted, or compressed 
into, or added to, one or more summary values. The second 
event, or set of events, will "inform" the relevant security (for 
example, termination and/or other consequence) control 
information (for example, budgets) at said VDE node of the audit 
receipt, modify expiration dates, provide key updates, and/or etc. 
In most cases, these events will be sent immediately to a site 
after an audit trail is received. In some cases, this transmission 
may be delayed to, for example, first allow processing of the audit 
trail and/or payment by a user to an auditor or other party. 
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In the preferred embodiment, the a dminis trative events for 
content objects and independently distributed 
methods/component assemblies are similar, but not necessarily 
identical. For example, key updates for a budget may control 
encryption of a billing trail, rather than decryption of object 
content. The billing trail for a budget is in all respects a method 
event trail. In one embodiment, this trail must include sufficient 
references into distribution records for encumbrances to allow 
reconciliation by a clearinghouse. This may occur, for example, if 
a grace period elapses and the creator of a budget allows 
unresolved encumbrances to ultimately yield automatic credits if 
an expired encumbrance is "returned" to the creator. 

Delivery of audit reports through a path of handling may 
be in part insured by an inverse (return of information) audit 
method. Many VDE methods have at least two pieces: a portion 
that manages the process of producing audit information at a 
user's VDE node; and a portion that subsequently acts on audit 
data. In an example of the handling of audit information bound 
for a plurality of auditors, a single container object is received at 
a clearinghouse (or other auditor). This container may contain 
(a) certain encrypted audit information that is for the use of the 
clearinghouse itself, and (b) certain other encrypted audit 
information bound for other one or more auditor parties. The two 
sets of information may have the same, overlapping and in part 
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different, or entirely different, information content. 
Alternatively, the clearinghouse VDE node may be able to work 
with some or all of the provided audit information. The audit 
information may be, in part, or whole, in some summary and/or 
analyzed form further processed at the clearinghouse and/or may 
be combined with other information to form a, at least in part, 
derived set of information and inserted into one or more at least 
in part secure VDE objects to be communicated to said one or 
more (further) auditor parties. When an audit information 
container is securely processed at said clearinghouse VDE node 
by said inverse (return) audit method, the clearinghouse VDE 
node can create one or more VDE administrative objects for 
securely carrying audit information to other auditors while 
separately processing the secure audit information that is 
specified for use by said clearinghouse. Secure audit processes 
and credit information distribution between VDE participants 
normally takes place within the secure VDE "black box," that is 
processes are securely processed within secure VDE PPE650 and 
audit information is securely communicated between the VDE 
secure subsystems of vDE participants employing VDE secure 
communication techniques (e.g., public key encryption, and 
authentication). 

This type of inverse audit method may specify the handling 
of returned audit information, including, for example, the local 
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processing of audit information and/or the secure passing along of 
audit information to one or more auditor parties. If audit 
information is not passed to one or more other auditor parties as 
may be required and according to criteria that may have been set 
by said one or more other auditor parties and/or content 
providers and/or control information providers during a 
permissions record specification and/or modification process, the 
failure to, for example, receive notification of successful transfer 
of required audit information by an auditor party, e.g., a content 
provider, can result in the disablement of at least some capability 
of the passing through party's VDE node (for example, 
disablement of the ability to further perform certain one or more 
VDE managed business functions that are related to object(s) 
associated with said audit or party). In this preferred 
embodiment example, when an object is received by an auditor, it 
is automatically registered and permissions record(s) contents 
are entered into the secure management database of the auditors 
VDE node. 

One or more permissions records that manage the creation 
and use of an audit report object (and may manage other aspects 
of object use as well) may be received by a user's system during 
an audit information reporting exchange (or other electronic 
interaction between a user and an auditor or auditor agent). 
Each received permissions record may govern the creation of the 
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next audit report object. After the reporting of audit information, 
a new permissions record may be required at a user's VDE node 
to refresh the capability of managing audit report creation and 
audit information transfer for the next audit reporting cycle. In 
our above example, enabling an auditor to supply one or more 
permissions records to a user for the purpose of audit reporting 
may require that an auditor (such as a clearinghouse) has 
received certain, specified permissions records itself from 
"upstream" auditors (such as, for example, content and/or other 
content control information providers). Information provided by 
these upstream permissions records may be integrated into the 
one or more permissions records at an auditor VDE (e.g., 
clearinghouse) installation that manage the permissions record 
creation cycle for producing administrative objects containing 
permissions records that are bound for users during the audit 
information reporting exchange. If an upstream auditor fails to 
receive, and/or is unable to process, required audit information, 
this upstream auditor may fail to provide to the clearinghouse (in 
this example) the required permissions record information which 
enables a distributor to support the next permission record 
creation/auditing cycle for a given one or more objects (or class of 
objects). As a result, the clearinghouse's VDE node may be 
unable to produce the next cycle's permissions records for users, 
and/or perform some other important process. This VDE audit 
reporting control process may be entirely electronic process 
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management involving event driven VDE activities at both the 
intended audit information receiver and sender and employing 
both their secure PPE650 and secure VDE co mmun ication 
techniques. 

In the preferred embodiment, each time a user registers a 
new object with her own VDE node, and/or alternatively, with a 
remote clearinghouse and/or distributor VDE node, one or more 
permissions records are provided to, at least in part, govern the 
use of said object. The permissions records may be provided 
dynamically during a secure UDE registration process 
(employing the VDE installation secure subsystem), and/or may 
be provided following an initial registration and received at some 
subsequent time, e.g. through one or more separate secure VDE 
communications, including, for example, the receipt of a physical 
arrangement containing or otherwise carrying said information. 
At least one process related to the providing of the one or more 
permissions records to a user can trigger a metering event which 
results in audit information being created reflecting the user's 
VDE node's, clearinghouse's, and/or distributor's permissions 
records provision process. This metering process may not only 
record that one or more permissions records have been created. 
It may also record the VDE node name, user name, associated 
object identification information, time, date, and/or other 
identification information. Some or all of this information can 
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become part of audit information securely reported by a 
clearinghouse or distributor, for example, to an auditing content 
creator and/or other content provider. This information can be 
reconciled by secure VDE applications software at a receiving 
auditor's site against a user's audit information passed through 
by said clearinghouse or distributor to said auditor. For each 
metered one or more permissions records (or set of records) that 
were created for a certain user (and/or VDE node) to manage use 
of certain one or more VDE object(s) and/or to manage the 
creation of VDE object audit reports, it may be desirable that an 
auditor receive corresponding audit information incorporated into 
an, at least in part, encrypted audit report. This combination of 
metering of the creation of permissions records; secure, encrypted 
audit information reporting processes; secure VDE subsystem 
reconciliation of metering information reflecting the creation of 
registration and/or audit reporting permissions with received 
audit report detail; and one or more secure VDE installation 
expiration and/or other termination and/or other consequence 
processes; taken together significantly enhances the integrity of 
the VDE secure audit reporting process as a trusted, efficient, 
commercial environment. 



791 



WO 96/27155 



PCT/US96/02303 



Secure Document Management Example 

VDE 100 may be used to implement a secure document 
management environment. The following are some examples of 
how this can be accomplished. 

In one example, suppose a law firm wants to use VDE 100 
to manage documents. In this example, a law firm that is part of 
a litigation team might use VDE in the following ways: 

1. to securely control access to, and/or other usage of, 
confidential client records, 

2. to securely control access, distribution, and/or other 
rights to documents and memoranda created at the 
law firm, 

3. to securely control access and other use of research 
materials associated with the case, 

4. to securely control access and other use, including 
distribution of records, documents, and notes 
associated with the case, 

5. to securely control how other firms in the litigation 
team may use, including change, briefs that have 
been distributed for comment and review, 

6. to help manage client billing. 
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The law firm may also use VDE to electronically file briefs with 
the court (presuming the court is also VDE capable) including 
providing secure audit verification of the ID (e.g., digital 
signature) of filers and other information pertinent to said filing 
procedure. 

In this example, the law firm receives in VDE content 
containers documents from their client's VDE installation secure 
subsystem(s). Alternatively, or in addition, the law firm may 
receive either physical documents which may be scanned into 
electronic form, and/or they receive electronic documents which 
have not yet been placed in VDE containers. The electronic form 
of a document is stored as a VDE container (object) associated 
with the specific client and/or case. The VDE container 
mechanism supports a hierarchical ordering scheme for 
organizing files and other information within a container; this 
mechanism may be used to organize the electronic copies of the 
documents within a container, A VDE container is associated 
with specific access control information and rights that are 
described in one or more permissions control information sets 
(PERCs) associated with that container. In this example, only 
those members of the law firm who possess a VDE instance, an 
appropriate PERC, and the VDE object that contains the desired 
document, may use the document. Alternatively or in addition, a 
law firm member may use a VDE instance which has been 



793 



WO 96/27155 



PCT/DS96/02303 



installed on the law firm's network server. In this case, the 
member must be identified by an appropriate PERC and have 
access to the document containing VDE object (in order to use the 
server VDE installation). Basic access control to electronic 
documents is enabled using the secure subsystem of one or more 
user VDE installations. 

VDE may be used to provide basic usage control in several 
ways. First, it permits the "embedding" of multiple containers 
within a single object. Embedded objects permit the "nesting" of 
control structures within a container. VDE also extends usage 
control information to an arbitrary granular level (as opposed to 
a file based level provided by traditional operating systems) and 
provides flexible control information over any action associated 
with the information which can be described as a VDE controlled 
process. For example, simple control information may be 
associated with viewing the one or more portions of documents 
and additional control information may be associated with 
editing, printing and copying the same and/or different one or 
more portions of these same documents. 

In this example, a "client" container contains all documents 
that have been provided by the client (documents received in 
other containers can be securely extracted and embedded into the 
VDE client container using VDE extraction and embedding 
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capabilities). Each document in this example is stored as an 
object within the parent, client VDE container. The "client" 
container also has several other objects embedded within it; one 
for each attorney to store their client notes, one (or more) for 
research results and related information, and at least one for 
copies of letters, work papers, and briefs that have been created 
by the law firm. The client container may also contain other 
information about the client, including electronic records of 
billing, time, accounting, and payments. Embedding VDE objects 
within a parent VDE content container provides a convenient 
way to securely categorize and/or store different information that 
shares similar control information. All client provided documents 
may, for example, be subject to the same control structures 
related to use and non-disclosure. Attorney notes may be subject 
to control information, for example, their use may be limited to 
the attorney who created the notes and those attorneys to whom 
such creating attorney expressly grants access rights. Embedded 
containers also provide a convenient mechanism to control 
collections of dissimilar information. For example, the research 
object(s) may be stored in the form of (or were derived from) VDE 
"smart objects" that contain the results of research performed by 
that object. Research results related to one aspect of the case 
retrieved from a VDE enabled LEXIS site might be encapsulated 
as one smart object; the results of another session related to 
another (or the same) aspect of the case may be encapsulated as a 
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different object. Smart objects are vised in this example to help 
show that completely disparate and separately delivered control 
information may be incorporated into a client container as 
desired and/or required to enforce the rights of providers (such as 
content owners). 

Control structures may be employed to manage any variety 
of desired granularities and/or logical document content 
groupings; a document, page, paragraph, topically related 
materials, etc. In this example, the following assumptions are 
made: client provided documents are controlled at the page level, 
attorney notes are controlled at the document level on an 
attorney by attorney basis, court filings and briefs are controlled 
at a document level, research information is controlled at 
whatever level the content provider specifies at the time the 
research was performed, and certain highly confidential 
information located in various of the above content may be 
identified as subject to display and adding comments only, and 
only by the lead partner attorneys, with only the creator and/or 
embedder of a given piece of content having the right to be 
otherwise used (printed, extracted, distributed, etc). 

In general, container content in this example is controlled 
with respect to distribution of rights. This control information 
are associated at a document level for all internally generated 
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documents, at a page level for client level documents, and at the 
level specified by the content provider for research documents. 

VDE control information can be structured in either 
complex or simple structures, depending on the participant's 
desires. In some cases, a VDE creator will apply a series of 
control structure definitions that they prefer to use (and that are 
supported by the VDE application managing the specification of 
rules and control information, either directly, or through the use 
of certified application compatible VDE component assemblies. 

In this example, the law firm sets up a standard VDE 
client content container for a new client at the time they accept 
the case. A law firm VDE administrator would establish a VDE 
group for the new client and add the VDE IDs of the attorneys at 
the firm that are authorized to work on the case, as well as 
provide, if appropriate, one or more user template applications. 
These templates provide, for example, one or more user interfaces 
and associated control structures for selection by users of 
additional and/or alternative control functions (if allowed by 
senior control information), entry of control parameter data, 
and/or performing user specific administrative tasks. The 
administrator uses a creation tool along with a predefined 
creation template to create the container. This creation template 
specifies the document usage (including distribution control 
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information) for documents as described above. Each electronic 
document from the client (including letters, memoranda, E-mail, 
spreadsheet, etc.) are then added to the container as separate 
embedded objects. Each new object is created using a creation 
template that satisfies that the default control structures 
specified with the container as required for each new object of a 
given type. 

As each attorney works on the case, they may enter notes 
into an object stored within the client's VDE container. These 
notes may be taken using a VDE aware word processor already in 
use at the law firm. In this example, a VDE redirector handles 
the secure mapping of the word processor file requests into the 
VDE container and its objects through the use of VDE control 
processes operating with one or more VDE PPEs. Attorney note 
objects are created using the default creation template for the 
document type with assistance from the attorney if the type 
cannot be automatically determined from the content. This 
permits VDE to automatically detect and protect the notes at the 
predetermined level, e.g. document, page, paragraph. 

Research can be automatically managed using VDE. 
Smart objects can be, used to securely search out, pay for if 
necessary, and retrieve information from VDE enabled 
information resources on the information highway. 
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Examples of such resources might include LEXIS, 
Westlaw, and other related legal databases. Once the 
information is retrieved, it may be securely embedded in the VDE 
content client container. If the smart object still contains 
unreleased information, the entire smart object may be 
embedded in the client's VDE container. This places the 
unreleased information under double VDE control requirements: 
those associated with releasing the information from smart object 
(such as payment and/or auditing requirements) and those 
associated with access to, or other usage of, client information of 
the specified type. 

Briefs and other filings may be controlled in a manner 
similar to that for attorney notes. The filings may be edited 
using the standard word processors in the law firm; with usage 
control structures controlling who may review, change, and/or 
add to the document (or, in a more sophisticated example, a 
certain portion of said document). VDE may also support 
electronic filing of briefs by providing a trusted source for 
time/date stamping and validation of filed documents. 

When the client and attorney want to exchange 
confidential information over electronic mail or other means, 
VDE can play an important role in ensuring that information 
exchanged under privilege, properly controlled, and not 
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inappropriately released and/or otherwise used. The materials 
(content) stored in a VDE content container object will normally 
be encrypted. Thus wrapped, a VDE object may be distributed to 
the recipient without fear of unauthorized access and/or other 
use. The one or more authorized users who have received an 
object are the only parties who may open that object and view 
and/or manipulate and/or otherwise modify its contents and VDE 
secure auditing ensures a record of all such user content 
activities. VDE also permits the revocation of rights to vise 
client/attorney privileged information if such action becomes 
necessary, for example, after an administrator review of user 
usage audit information. 

Large Organization Example 

In a somewhat more general example, suppose an 
organization (e.g., a corporation or government department) with 
thousands of employees and numerous offices disposed 
throughout a large geographic area wishes to exercise control 
over distribution of information which belongs to said 
organization (or association). This information may take the 
form of formal documents, electronic mail messages, text files, 
multimedia files, etc,, which collectively are referred to as 
"documents" 
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